Hallo zusammen,
ich habe in den letzten Wochen in Bezug auf enocean mit eltako-Komponenten und fhem viel in diesem forum und den wiki Seiten gelesen. Allerdings sind mir einige Sachverhalte noch nicht klar und hoffe, das jemand helfen kann!
Infrastruktur:
1 x Verteilung im Keller
1 x Unterverteilung im Gartenhaus
dezentrale Aktoren im EG, OG und DG
dezentrale Sensoren im EG, OG und DG
Verteilung Keller:
- 1 x FAM 14
- 1 x FTS 14EM (Eingänge, Reed-Kontakt, Lichtschranke, Taster, etc)
- 1 x FSR 14-4x
- 1 x FBA 14 (Buskoppler-> Garten)
- 1 x enocean pi
Verteilung Garten:
- 2 x FTS 14-4x
- 1 x FBA 14 (Buskoppler-> Keller)
Meines Erachtens gibt es zwei Möglichkeiten, den pi einzubinden:
Möglichkeit 1:
- enocean pi über FAM 14
- FTS14-FA um Telegramme aus dem RS485 (z.B. FTS14EM) in den Gebäudefunk zu senden,
damit diese von dezentralen Aktoren und dem pi gelernt werden können.
Möglichkeit 2:
- pi über FGW14-USB in den RS485 hängen
- FTD 14 sendet Telegramme aus dem RS485 (vom pi und dem FTS 14EM) in den Gebäudefunk,
damit diese von dezentralen Aktoren gelernt werden können.
Kann jemand sagen, ob das vom Aufbau her korrekt ist? Oder benötigt man für Möglichkeit 2
noch das FTS14-FA? Kann man anstelle des FTS14-FA in Möglichkeit 1 auch das FTD 14 nutzen?
Ich überblicke das irgendwie nicht und suche einen Rat, wie man alles am Besten und geschicktesten ankoppelt.
Das enocean pi Modul funkt nur im begrenzten Radius und man braucht auf jeden Fall externe Antennenm wenn man aus dem Keller ins OG funkten will. Ein Test mit einem Wandsender, den ich im 1.OG betätigt habe, wird zwar vom FAM 14 im Keller empfangen, der enocean pi im gleichen Raum kriegt das Signal nicht mit. Die rote Antenne des enocean Moduls habe ich so gut es ging aufrecht gestellt.
Besten Dank im Voraus,
Spartacus.
Danke
Sparatcus.
Zitat von: Spartacus am 15 September 2014, 21:24:06
Kann jemand sagen, ob das vom Aufbau her korrekt ist? Oder benötigt man für Möglichkeit 2
noch das FTS14-FA? Kann man anstelle des FTS14-FA in Möglichkeit 1 auch das FTD 14 nutzen?
Hallo,
da ich mit den Tasterschnittstellen noch keine Erfahrung gesammelt habe, kann ich hier nur Vermutungen anstellen. Das FTD14 wird wohl auch Schaltertelegramme funken können, so lange die als normale EnOcean-Telegramme auf dem RS485-Bus landen, die Einrichtung ist aber sicherlich komplizierter als mit dem FTS14FA, da man sicherlich mindestens jedes FTS14-EM einzeln einlernen müsste.
Wenn du nicht zwingend Direktverknüpfungen von Sender auf Aktor einrichten willst, wäre eine weitere Möglichkeit, die Tastsignale über notifys in fhem auf die dezentralen Aktoren zu verschalten. Das geht auf jeden Fall mit dem FTD14, mache ich hier z.B. auch für einen FT55, dessen Tastaktion dann über FHEM einen FSR61-230V ein- oder ausschaltet.
Was Taster angeht bin ich mittlerweile von physikalisch verdrahteten Tastern abgekommen - die FT55 sind kompakter und billiger, brauchen keine Batterie, keine Unterputzdose und kein Kabel, und das Funksignal reicht von jeder Stelle des Hauses bis zum Schaltschrank. Und selbst wenn das nicht so wäre, haben die meisten dezentralen Aktoren von Eltako mittlerweile sogar Level-1-Repeater eingebaut. Für Reed-Kontakte u.ä. macht natürlich eine physikalische Verdrahtung allein aus ökonomischen Gründen vermutlich schon noch Sinn, da sind die Funkfensterkontakte mit mindestens 50€ sicher deutlich teurer. (Rechnung für die Taster: 4fach-Serientaster gibt es AFAIK nur von Berker zu ca. 15€/Stück (ohne Abdeckung und Rahmen, die kommen also noch dazu!), ich brauche dann noch einige Meter Telefonkabel, muss Schlitze stemmen, Unterputzdosen bohren, und schließlich brauche ich noch fast ein halbes FTS14-EM, das je nachdem wo man es kauft anteilig mit 20-25€ zu Buche schlägt - ein FT55 kostet mich ca. 30€).
Viele Grüße
crispinus
Hallo crispinus,
Besten Dank! Ich komme um das FTS14-EM allerdings nicht herum, der Reed Kontakt an der Haustür und die Lichtschranke (open Colector) im Eingangsbereich sind nicht so einfach zu ersetzten. Ich werde mich mal bei eltako erkundigen, ob und wie man das FTD14 anstelle des FTS14-FA nutzen kann. 3 Funkantennen in einem RS485-BUS möchte ich nicht unbedingt haben.
Ich habe schon vor, die Sender direkt in die Aktoren einzulernen, da ich mich nicht von fhem abhängig machen möchte. Wenn der pi einmal ausfällt, würde nix mehr laufen...
Im Prinzip wäre ich Deiner Ansicht nach mit Möglichkeit 1 voll funktionsfähig, wenn ich die Reichweitenbeschränkung des enocean pi mal außen vor lasse.
Ich könnte Telegramme vom FTS14-EM auch in dezentrale Aktoren einlernen und auch der pi würde diese Telegramme empfangen können. Der Einzige Grund für ein FTD14 wäre der, wenn man den pi direkt in den RS485-Bus packt um somit die Antennenleistung über das FTD zu erhöhen, richtig?
Gruß,
Spartacus.
Zitat von: Spartacus am 16 September 2014, 12:11:44
Ich habe schon vor, die Sender direkt in die Aktoren einzulernen, da ich mich nicht von fhem abhängig machen möchte. Wenn der pi einmal ausfällt, würde nix mehr laufen...
Ja, das ist wohl richtig. Da finde ich es echt schade, dass die meisten EnOcean-Aktoren noch kein Remote-Teach-In beherrschen, da hat HomeMatic tatsächlich mal einen deutlichen Vorteil, allein schon durch die dort eingebaute State Machine.
In meinem Fall habe ich aber zum Glück genügend verschiedene Rechner, die im Falle eines Falles für mein Olinuxino die Arbeit von FHEM übernehmen können, die Konfiguration wird natürlich ohnehin gebackupt. So kann ich bei einem Defekt des Olinuxino innerhalb von Minuten einen anderen Rechner mit der Steuerung der Heimautomatisierung beauftragen. Da ich auch viele Selbstbau-Relais über meinen Arduino und Finder Schaltschrankrelais einsetze, wäre das meiste an Licht ohnehin nicht über Direktverknüpfungen zu steuern. Deswegen setze ich nicht auf Direktverknüpfungen, denn durch das fehlende Remote-Teach-In ist es doch mit teils größerem Aufwand verbunden, wenn man eine Funktion mal ändern möchte (irgendwelche Dosen aufmachen / Lampen abhängen um an die FSR61 zu kommen oder so, und dann noch den einzulernenden Taster ausbauen um ihn neu ins FSR61 einzulernen ohne immer zwischen dem eigentlichen Einbauort und dem FSR61 hin und her rennen zu müssen...)
Zitat von: Spartacus am 16 September 2014, 12:11:44
Im Prinzip wäre ich Deiner Ansicht nach mit Möglichkeit 1 voll funktionsfähig, wenn ich die Reichweitenbeschränkung des enocean pi mal außen vor lasse.
Ich könnte Telegramme vom FTS14-EM auch in dezentrale Aktoren einlernen und auch der pi würde diese Telegramme empfangen können. Der Einzige Grund für ein FTD14 wäre der, wenn man den pi direkt in den RS485-Bus packt um somit die Antennenleistung über das FTD zu erhöhen, richtig?
Ja, so ist es. Für zumindest ein FGW14 fällt mir aber gerade noch ein guter Grund ein: das FAM14 ist in der Lage, von den Busaktoren in regelmäßigen Intervallen den Status abzufragen (z.B. von meinen FUD14, oder auch von FSR14-4x, wenn man welche einsetzt). Die Informationen können vom FGW14 mitgelesen werden und so hat FHEM in regelmäßigen (sehr kurzen) Abständen aktualisierte Readings über den tatsächlichen Zustand der Busaktoren. Prinzipiell wird das wohl auch ohne FGW14 über EnOcean pi o.ä. funktionieren, da die Busaktoren ja auf Schaltaktionen auch Bestätigungstelegramme erzeugen, die dann vom FAM14 ausgesendet werden, diese könnte man wiederum in FHEM einlernen denke ich. Vermutlich wäre das aber nicht so zuverlässig, wie die direkte, mehrmals in der Sekunde aktualisierte Information übers FGW14.
Ein kombinierter Einsatz von FGW14/FAM14 zum Statusempfang und EnOcean pi zum Senden ist in FHEM so aktuell nicht sinnvoll möglich, denke ich, denn pro Device kann man ja nur ein IODev angeben, und wenn man jetzt z.B. ein FSR61-230V hat, das bidirektional arbeiten kann, so landet man dann bei zwei Devices, nämlich einem über FGW14/FAM14 befüllten mit den aktuellen Readings und einem reinen Steuerdevice für das Funken mit EnOcean pi. Wirkt für mich unschön und auch unpraktisch. Inwiefern die Möglichkeit bestünde, das EnOcean-Modul einfach um ein IODev fürs Empfangen und eins fürs Senden pro Device zu erweitern und wie kompliziert das wäre kann ich im Moment nicht einschätzen.
VG
crispinus
Hallo crispinus,
habe mit eltako gesprochen. Das FTD 14 kann die Signale vom FTS 14-EM nicht verarbeiten. Das heißt, man braucht zwingend den Weg über das FTS 14-FA.
Ein andere Möglichkeit wäre noch, über das FTS14-EM einen Aktor im RS485 anzusprechen und dessen Statustelegramm über das FAM 14 in den Gebäudefunk zu senden. Damit könnte man dann weitere dezentrale Aktoren füttern. Das ist aber m.E. Quatsch, da man dann einen Kanal des RS485-Aktors opfern muss.
Ich denke, ich mache das mal so, wie im Anhang aufgemalt. Den enocean pi habe ich ja schon! Das FTS 14-EM werde ich dann gemäß der Regel über ein FTS 14-FA in den Gebäudefunk einbinden.
Vielleicht gibt´s für den raspberry irgendwann wieder ein enocean Modul mit externer Antenne, sodass ich durch das ganze Haus funken kann...
Spartacus
Hallo,
Ich habe jetzt einen FMS61NP testweise an mehreren Stellen im Haus platziert um die Empfangsqualität von enocean zu testen. Ich muss feststellen, dass der Aktor ein sehr eingeschränkten Empfangsradius im Gegensatz zum FAM 14 hat. Einen PTM 210 Sender habe ich direkt eingelernt und schaffe es gerade mal innerhalb der Etage (Metallständer mit je 2 x Gipskarton) den Aktor zu schalten. Im Keller (bei geöffneten Türen) nicht einmal in den Nachbarraum (keine Betonwände innerhalb der Etage, nur KS).
Wenn ich den gleichen PTM 210 in einen Aktor im RS485 Bus (über das FAM14) anlerne, schaffe ich es vom OG über EG bis in den Keller.
Leider habe ich zur Zeit nur diesen einen dezentralen Aktor und würde gerne mal in die Runde fragen, ob diese Reichweite "normal" ist. Das der enocean pi genauso schwach auf der Brust ist, habe ich schon berichtet, aber von dem Aktor bin ich ein wenig enttäuscht. Der steckt derzeit noch nicht einmal in einer UP- Schalterdose
Spartacus
Hallo,
Ich bin mir immer noch nicht sicher, wie ich Funktelegramme aus dem RS485- Bus am Besten in fhem auswerten kann.
Wäre folgendes Szenario denkbar?
Den pi über das USB GW in den RS485 hängen. der pi bekommt ein enocean Modul. Signale von einem FTS14 EM können vom pi direkt aus dem BUS gelesen werden und über das enocean Modul in den Gebäudefunk weitergeleitet werden, um z.B. weitere dezentrale Aktoren anzusteuern. Außerdem könnte der pi auch die zentralen Aktoren im Bus ansteuern.
Hintergründe:
Ich habe das FTS14EM im Bus und habe einen Aktor im Bus als Relais angelernt. Solange der Reed Kontakt am FTS14 EM geschlossen ist, so lange wird das Relais am FSR14-4x angezogen. Das macht in der Praxis aber keinen Sinn!
Das Relais muss nach Zeit t wieder abfallen. Das kann man zwar am FSR14-4x einstellen, aber nicht getrennt für alle 4 Kanäle.
Der pi sollte das dann regeln können.
Könnte das klappen? Dann würde ich einen enocean Pi einfach in den RS485 hängen.
Danke und Gruß
Spartacus
Moin,
hat niemand eine Idee dazu, oder ein Tipp, wie man es herausfinden kann (ohne das FGW14-USB gleich zu kaufen 8))?
Danke Spartacus
Eine Möglichkeit wäre evtl., das Telegramm vom FTS14 EM auch in FHEM einzulernen und mit einer Kombination aus notify und at nach einer Zeitdauer x das FSR auszuschalten. Das setzt natürlich voraus, dass das FTS14EM nicht kontinuierlich das "Kontakt geschlossen" Telegramm sendet sondern lediglich dann, wenn ein Zustandswechsel vorliegt. Testen könnte man das wohl auch mit EnOcean Pi, da müssten über das FAM14 die Telegramme ja entsprechend auf dem Bus landen. Setzt aber auch voraus, dass FHEM / das EnOcean Pi die Telegramme vom FTS14 EM mitbekommt, da braucht man dann ja wohl dieses Sendemodul aus dem FTS-System. Wahlweise (und vielleicht sogar vorzuziehen) wäre die Reaktion auf das Bestätigungstelegramm des FSRs möglich, das müsste dann sogar ohne FTD14 nur mit dem FAM14 gehen, was ja Bestätigungstelegramme herausfunkt.
Was die Reichweite vom Enocean Gebäudefunk angeht, wird ja in der offiziellen Dokumentation unter günstigsten Bedingungen von max. 30m Reichweite gesprochen, in einem Neubau muss man wohl eher vom ungünstigsten Fall von 10m / evtl 20m ausgehen. Die Dokumentation weist auch darauf hin, dass diese Reichweite z.B. beim Einbau in Unterputzdosen nochmals deutlich sinkt. Bei den Einbaumodulen kommt sicherlich zusätzlich noch zum Tragen, dass die Länge der Antenne für die verwendeten knapp 870 MHz suboptimal ist. Da haben die Hutschienenmodule mit der entsprechenden externen Antenne einfach deutliche Vorteile. Mit meiner Zentralsteuerung aus FAM14 und FTD14 je mit Antenne habe ich keine Probleme, auch den vom Schaltschrank am weitesten entfernten Aktor (durch eine Betondecke und zwei Brandschutzmauern aus Ziegelsteinen) sicher zu erreichen. Auch die Bestätigungstelegramme des Aktors (ein FSR61) treffen zuverlässig am FAM14 ein.
Zumindest die aktiven Eltako-Aktoren (nahezu alle aktuell gebauten FSR61 IMHO) verfügen aber sämtlich über einen eingebauten Level-1-Repeater. Damit lässt sich das Reichtweitenproblem etwas entschärfen, wenn man davon ausgeht, dass sich in jedem Raum des Hauses zumindest ein FSR61 befindet, müsste man eigentlich eine ausreichende Abdeckung erreichen können. Ansonsten gibt es ja auch noch Auf- oder Unterputzrepeater, die dann Level-1 oder wahlweise sogar -2 können.
Was man aus meiner Sicht auch noch bedenken sollte: Wenn man deshalb mit Direktverknüpfungen arbeitet, um nicht auf ein möglicherweise ausfallendes zentrales System angewiesen zu sein, so werden sich die meisten Schaltfunktionen wohl doch in einem Raum abspielen, wo dann eben der Schalter neben der Tür Lampenauslässe oder Steckdosen des Raumes schaltet. Visu ist ja auch nicht, wenn die Zentrale ausgefallen ist. Und für Komfortfunktionen wie z.B. ein "Zentral aus" ist man dann eben ggf. auf die Zentralsteuerung angewiesen - aber es ist sicherlich auch keine zu große Einschränkung, wenn das "Zentral aus" mal einige Tage nicht funktioniert, bis ein Ersatz für die defekte Zentralsteuerung eingetroffen ist.
Die positive Seite an der eingeschränkten EnOcean-Reichweite: für möglicherweise böswillige Fremde ist es auch ohne aktive Verschlüsselung sicherlich schwieriger, eine Heimautomatisierung zu kapern, jedenfalls wenn man nicht Equipment auffährt, dass dann möglicherweise auch die Bundesnetzagentur auf den Plan ruft.
Hallo crispinus,
am FTS14-EM ist zu Testzwecken ein Reed Kontakt, der einen Kanal des FSR14 ansteuert (solange Kontakt geschlossen, solange zieht Relais an). Das Bestätigungstelegramm vom FSR14 wird dann über das FAM14 gesendet und fhem wertet es wie folgt aus:
2014-09-29_21:57:23 EnO_FSR14_GH_A on
2014-09-29_21:57:24 EnO_FSR14_GH_A off
Die Frage ist nun, ob das FTS-EM in fhem direkt als "Schalter" eingelernt werden kann, wenn der pi, mit einem "Beinchen" über das USB-GW im RS485 hängt. Mit dem FTS 14-FA kann man die Telegramme des EMs funken und der enocean pi würde sie dann auch wie ein normales PTM empfangen. Das hat mir eltako so bestätigt. Das wäre ja alles kein Thema, aber für jedes FTS14-EM braucht man ein FTS14-FA. Deshalb fände ich es eleganter, den pi über das GW in den BUS zu hängen um die 10 Eingänge eines EMs direkt in fhem einzulernen und auszuwerten.
Im Übrigen reicht es nicht, das EM direkt in den FSR14 einzulernen, da der Reed-Kontakt u.a. einen Aktor mit "on-for-timer" ansteuern soll. Dafür brauche ich halt fhem um es umzusetzen.
Wenn man die Reichweitenprobleme mit Repeatern lösen kann, dann werde ich das wohl machen. Ich hoffe nur, das es keinen Funksalat gibt, wen mehrere Repeater im Einsatz sind. Ich bin leider auf die UP-Aktoren angewiesen, da die Hütte schon 12 Jahre alt ist und damals zum größten Teil herkömmlich verkabelt wurde. Auch wenn es tiefe Schalterdosen sind, wird es vermutlich ziemlich eng in den Dosen. Ich hoffe das es klappt!
Spartacus
Hallo zusammen,
ich habe heute noch mal mit eltako gesprochen. Das FTS14-EM erzeugt auf dem RS485 BUS die Telegramme "pressed", "released", "on", "off", ähnlich eines Tasters.
Somit müsste es doch eigentlich machbar sein, den pi über das USB-GW in den RS485 zu hängen und die Telegramme des FTS14-EM in fhem einzulernen.
Über das enocean Modul des pi sollte es doch dann möglich sein, dezentrale Aktoren anzusteuern, bzw. die zentralen Aktoren über das USB-GW des pi.
Ich würde das GW jetzt bestellen und es austesten, oder habe ich hier etwas grundsätzliches übersehen? Kann fhem zwei enocean Devices verwalten (enocean pi-Modul und das USB-GW)? Oder ist das alles viel zu kompliziert?
Danke und Gruß,
Spartacus.
P.S.
Der Techniker meinte, man könne ggf. sogar das FAM14 per USB ankoppeln um die Telegramme mitzuschneiden. Hat das schon einmal jemand versucht?
Zitat von: Spartacus am 29 September 2014, 22:46:59
Die Frage ist nun, ob das FTS-EM in fhem direkt als "Schalter" eingelernt werden kann, wenn der pi, mit einem "Beinchen" über das USB-GW im RS485 hängt. Mit dem FTS 14-FA kann man die Telegramme des EMs funken und der enocean pi würde sie dann auch wie ein normales PTM empfangen. Das hat mir eltako so bestätigt. Das wäre ja alles kein Thema, aber für jedes FTS14-EM braucht man ein FTS14-FA. Deshalb fände ich es eleganter, den pi über das GW in den BUS zu hängen um die 10 Eingänge eines EMs direkt in fhem einzulernen und auszuwerten.
Wenn wie in deinem Nachfolgepost beschrieben das FTS14EM sich auch auf dem Bus wie ein Taster verhält, sollte das wohl kein Problem sein. Dann ist die einzige noch offene Frage, ob ein FTS14EM 10 verschiedene Bus-IDs erhält oder wie sonst 20 verschiedene Zustände signalisiert werden (vorgesehen sind IMHO ja lediglich vier Kanäle pro EnOcean-Device, also die Paare A,B,C und D I/0). Je nachdem müsste man dann eben für ein FTS14EM mehrere Devices in FHEM anlegen / bzw. per autocreate anlegen lassen.
Zitat von: Spartacus am 29 September 2014, 22:46:59
Wenn man die Reichweitenprobleme mit Repeatern lösen kann, dann werde ich das wohl machen. Ich hoffe nur, das es keinen Funksalat gibt, wen mehrere Repeater im Einsatz sind. Ich bin leider auf die UP-Aktoren angewiesen, da die Hütte schon 12 Jahre alt ist und damals zum größten Teil herkömmlich verkabelt wurde. Auch wenn es tiefe Schalterdosen sind, wird es vermutlich ziemlich eng in den Dosen. Ich hoffe das es klappt!
Der Funksalat wird ja letztlich dadurch vermieden, dass ein Signal maximal zwei Mal (und dann vermutlich jeweils leicht zeitverzögert) weiterverstärkt wird (Level-1-Repeater verstärken Telegramme von Schaltern bzw. Bestätigungstelegramme von Aktoren, Level-2-Repeater zusätzlich die Telegramme von Level-1-Repeatern). Das beste für deinen Fall wäre vermutlich, mal den Einsatz eines FRP70-230V in Kombination mit einer FA250 zu erproben, wahlweise gibts das Teil auch als FRP14 für die Hutschiene, um es unten in den Verteilerschrank zu hängen (ebenfalls mit Anschlussmöglichkeit für die FA250). Dann kommst du evtl. um den Einsatz mehrere Unterputzrepeater herum, da das FAM14 im Moment ja auch alles im Haus mitbekommt
Zitat von: Spartacus am 01 Oktober 2014, 13:56:26
Über das enocean Modul des pi sollte es doch dann möglich sein, dezentrale Aktoren anzusteuern, bzw. die zentralen Aktoren über das USB-GW des pi.
Ich würde das GW jetzt bestellen und es austesten, oder habe ich hier etwas grundsätzliches übersehen? Kann fhem zwei enocean Devices verwalten (enocean pi-Modul und das USB-GW)? Oder ist das alles viel zu kompliziert?
FHEM kann soweit ich weiß beliebig viele verschiedene EnOcean-TCM-Module verwalten, die werden ja jeweils als separate Instanz per Define angelegt, man muss dann nur bei nicht per autocreate angelegten EnOcean-Devices das jeweils korrekte IODev setzen. Aber wenn ich dein Vorhaben jetzt richtig verstehe, bleibt doch weiterhin der Nachteil der unzureichenden Reichweite des EnOcean-Pi-Moduls zur Ansteuerung dezentraler Aktoren?
Zitat von: Spartacus am 01 Oktober 2014, 13:56:26
P.S.
Der Techniker meinte, man könne ggf. sogar das FAM14 per USB ankoppeln um die Telegramme mitzuschneiden. Hat das schon einmal jemand versucht?
Nö, aber wenn das stimmt dann wär das FGW14-USB ja ein ziemlicher Beschiss bzw. für die FHEM-Anbindung überflüssig :D. Dem Datenblatt kann man entnehmen, dass die PC-Software von Eltako beim Anschluss ans FAM14 per USB in der Lage ist, den Bus auszulesen und die Busdevices auch zu programmieren, dass das FAM14 dabei dann aber im Prinzip die gleichen Funktionen bietet wie das FGW14, also Funk- und Bustelegramme auf die USB-Schnittstelle weiterleitet, ist dort so nicht vermerkt. Muss ich glatt mal irgendwann probieren, ich weiß auch gar nicht, ob sich das FAM14 dann ebenfalls als USB-FTDI-Device ausgibt und funktioniert. Du hast ja dein FAM14 auch schon - dann könntest du das ja eigentlich mal probieren. Im Zweifelsfall würde ich unterstellen, dass die Einrichtung ähnlich bzw. genau so funktionieren müsste, wie wenn du dich mit dem Pi ans FGW14-USB angebunden hättest.
VG
crispinus
Guten Abend,
ich habe das gerade mal ausprobiert - FHEM über USB direkt am FAM14 erlaubt tatsächlich die Nachrichten auf dem RS485 Bus mitzuhören und auch Nachrichten in den Bus zu senden.
Ich empfange auch über den Bus die Nachrichten aus dem Enocean Funk und kann auch Nachrichten an ein FTD14 absetzen welcher dieser in den Funk sendet.
Verstehe daher jetzt auch nicht wofür man dann noch ein FGW14 für die Verbindung mit einem Host benötigt (RS232?).
Gruß, Norberto
Hallo Noberto,
Wie h#st Du das FAM 14 an fhem angebunden? So wie im Wiki unter FGW14 beschrieben?
Das werde ich dann auch ldirekt mal ausprobieren
Christian
Hallo Christian,
Ja. Bitte nicht von 'TCM310' irritieren lassen.
# USB Verbindung an FAM14
define TCM310 TCM 120 COM10@57600
attr TCM310 alias Eltako FAM14
attr TCM310 sendInterval 100
attr TCM310 verbose 3
Gruß, Norbert
Hi,
sorry für die blöde Frage, aber wie hast Du den COM Port ermittelt? Ich kriege zum FAM14 nur ein disconnect.
Christian
NACHTRAG:
Habe das jetzt so gemacht, und das DEVICE wird geöffnet:
define TCM310 TCM 120 /dev/ttyAMA0@57600
Nur ich bekomme ein Timeout, wenn ich etwas lesen möchte. Auf welcher Position hast Du den Drehschalter vom FAM14
PCT14 zeigt bei einer Verbindung den COM Port unten rechts an. Gruß, Norbert
Nachtrag 1: ich hatte den Test mit FHEM unter Windows gemacht
Nachtrag 2: ich meine ich hatte den Drehschalter auf 5, kann ich erst heute Abend prüfen
Gruß, Norbert
Hallo,
auf die Schnelle am rpi ausprobiert:
define FAM14 TCM 120 /dev/ttyUSB0@57600
attr FAM14 sendInterval 100
attr FAM14 verbose 3
funzt.
allerdings liefert der Befehl get baseID dieses Ergebnis:
Unknown command: AB58000000000000000000
wenn ich das FAM14 auf teach setzte, und einen Aktor im RS485-BUS betätige, werden folgende Devices angelegt:
EnO_switch_00000001
EnO_switch_00000003
EnO_switch_00000005
Sieht erst einmal ganz gut aus. Jetzt muss ich mal das FTS14-EM anschliessen..
Christian.
NACHTRAG:
get version liefert:
get version: Bogus answer received: 000000000005ACA55AAB4B000000000000000000F6A55AABFC000000000000000006ADA55AABFC000000000000000007AE
..sagt mir nichts!
Hallo,
habe mal das über USB gekoppelte FAM14 in fhem auf "teach" gesetzt und den FTS14EM mit Eingangs-Kanal 2 eingelernt.
...das sieht so aus.
2014-10-02_21:40:33 EnO_switch_00001002 buttons: released
2014-10-02_21:40:33 EnO_switch_00001002 buttons: released
2014-10-02_21:40:37 EnO_switch_00001002 buttons: pressed
2014-10-02_21:40:37 EnO_switch_00001002 channelB: B0
2014-10-02_21:40:37 EnO_switch_00001002 B0
2014-10-02_21:40:38 EnO_switch_00001002 buttons: released
2014-10-02_21:40:38 EnO_switch_00001002 buttons: released
2014-10-02_21:40:42 EnO_switch_00001002 buttons: pressed
2014-10-02_21:40:42 EnO_switch_00001002 channelB: B0
2014-10-02_21:40:42 EnO_switch_00001002 B0
2014-10-02_21:40:43 EnO_switch_00001002 buttons: released
2014-10-02_21:40:43 EnO_switch_00001002 buttons: released
2014-10-02_21:45:21 EnO_switch_00001002 buttons: pressed
2014-10-02_21:45:21 EnO_switch_00001002 channelB: BI
2014-10-02_21:45:21 EnO_switch_00001002 BI
2014-10-02_21:45:22 EnO_switch_00001002 buttons: released
2014-10-02_21:45:22 EnO_switch_00001002 buttons: released
2014-10-02_21:46:49 EnO_switch_00001002 buttons: released
2014-10-02_21:46:49 EnO_switch_00001002 buttons: released
2014-10-02_21:46:49 EnO_switch_00001002 buttons: pressed
2014-10-02_21:46:49 EnO_switch_00001002 channelB: BI
2014-10-02_21:46:49 EnO_switch_00001002 BI
2014-10-02_21:46:50 EnO_switch_00001002 buttons: released
2014-10-02_21:46:50 EnO_switch_00001002 buttons: released
2014-10-02_22:05:39 EnO_switch_00001002 buttons: released
2014-10-02_22:05:39 EnO_switch_00001002 buttons: released
Eingangs-Kanal 1 des FTM14-EM habe ich an Aktor 4 des Bus-internen FSR14-4x angelernt. Jetzt werden zwei neue Switches von fhem erkannt.
1. EnO_switch_00001001
2. EnO_switch_00000004
in EnO_switch_00001001 steht so ziemlich das Gleiche wie in EnO_switch_00001002:
2014-10-02_21:35:49 EnO_switch_00001001 buttons: pressed
2014-10-02_21:35:49 EnO_switch_00001001 channelB: B0
2014-10-02_21:35:49 EnO_switch_00001001 B0
2014-10-02_21:35:50 EnO_switch_00001001 buttons: released
2014-10-02_21:35:50 EnO_switch_00001001 buttons: released
2014-10-02_21:35:57 EnO_switch_00001001 buttons: pressed
2014-10-02_21:35:57 EnO_switch_00001001 channelB: B0
2014-10-02_21:35:57 EnO_switch_00001001 B0
2014-10-02_21:35:57 EnO_switch_00001001 buttons: released
2014-10-02_21:35:57 EnO_switch_00001001 buttons: released
2014-10-02_21:36:30 EnO_switch_00001001 buttons: pressed
2014-10-02_21:36:30 EnO_switch_00001001 channelB: B0
2014-10-02_21:36:30 EnO_switch_00001001 B0
2014-10-02_21:36:30 EnO_switch_00001001 buttons: released
2014-10-02_21:36:30 EnO_switch_00001001 buttons: released
2014-10-02_21:37:10 EnO_switch_00001001 buttons: pressed
2014-10-02_21:37:10 EnO_switch_00001001 channelB: B0
2014-10-02_21:37:10 EnO_switch_00001001 B0
2014-10-02_21:37:10 EnO_switch_00001001 buttons: released
2014-10-02_21:37:10 EnO_switch_00001001 buttons: released
2014-10-02_21:37:25 EnO_switch_00001001 buttons: released
2014-10-02_21:37:25 EnO_switch_00001001 buttons: released
2014-10-02_21:37:30 EnO_switch_00001001 buttons: pressed
2014-10-02_21:37:30 EnO_switch_00001001 channelB: B0
2014-10-02_21:37:30 EnO_switch_00001001 B0
2014-10-02_21:37:35 EnO_switch_00001001 buttons: released
2014-10-02_21:37:35 EnO_switch_00001001 buttons: released
2014-10-02_21:37:42 EnO_switch_00001001 buttons: pressed
2014-10-02_21:37:42 EnO_switch_00001001 channelB: B0
2014-10-02_21:37:42 EnO_switch_00001001 B0
2014-10-02_21:37:49 EnO_switch_00001001 buttons: released
2014-10-02_21:37:49 EnO_switch_00001001 buttons: released
2014-10-02_22:04:21 EnO_switch_00001001 buttons: released
2014-10-02_22:04:21 EnO_switch_00001001 buttons: released
EnO_switch_00000004 (nehme an, das ist das Bestätigungsprotokoll des Aktors)
2014-10-02_22:04:21 EnO_switch_00000004 buttons: pressed
2014-10-02_22:04:21 EnO_switch_00000004 channelB: BI
2014-10-02_22:04:21 EnO_switch_00000004 BI
2014-10-02_22:11:39 EnO_switch_00000004 buttons: pressed
2014-10-02_22:11:39 EnO_switch_00000004 channelB: B0
2014-10-02_22:11:39 EnO_switch_00000004 B0
2014-10-02_22:11:40 EnO_switch_00000004 buttons: pressed
2014-10-02_22:11:40 EnO_switch_00000004 channelB: BI
2014-10-02_22:11:40 EnO_switch_00000004 BI
2014-10-02_22:11:43 EnO_switch_00000004 buttons: pressed
2014-10-02_22:11:43 EnO_switch_00000004 channelB: B0
2014-10-02_22:11:43 EnO_switch_00000004 B0
2014-10-02_22:11:44 EnO_switch_00000004 buttons: pressed
2014-10-02_22:11:44 EnO_switch_00000004 channelB: BI
2014-10-02_22:11:44 EnO_switch_00000004 BI
Den Aktor des FSR 14 habe ich in Stellung 10 als "Universaltaster ER", da ein Reed-Kontakt den Eingang am EM bedient.
Kann jemand mit den Werten etwas anfangen? Ich verstehe die Zusammenhänge noch nicht und ob man das irgendwie in fhem nutzbar machen kann. Fhem erkennt die Eingänge als Switch und nicht als Sensor.
Spartacus
Das sieht doch schon mal sehr gut aus. Die Telegramme vom FTS14EM kann man dann so nutzbar machen:
define SchalterAktion notify EnO_switch_00001002:B0 set XYZ on
Nützlich wäre es jetzt nur noch zu wissen, unter welchen Umständen BI respektive B0 gesetzt wird (Kontakt geöffnet/geschlossen?)
Zum korrekten Einlernen des FSR14-4x siehe http://www.fhemwiki.de/wiki/EnOcean-FSR14-4x-RS485-Bus-Schaltaktor-4-Kanal-Stromsto%C3%9F-Schaltrelais .
Als Device kannst du das verwenden, was FHEM dir automatisch angelegt hat (d.h. du musst für dieses Device die Attribute setzten wie im Wiki-Artikel angegeben). Da das FAM14 genau so wie das FGW14 keine eigene BaseID auf dem RS485-Bus haben wird, kannst du für das subDef eine beliebige gültige, auf dem Bus noch nicht existierende Adresse auswählen.
Guten Morgen,
Funktion und Konfiguration des FTS14EM sind auf den Seiten 9 bis 11 in folgendem Dokument genau erklärt:
www.eltako.com/fileadmin/downloads/de/_bedienung/RS485-Bus-Reiheneinbaugeraete_Baureihe_14_Planungshilfe_und_Betriebsanleitung_dt.pdf (http://www.eltako.com/fileadmin/downloads/de/_bedienung/RS485-Bus-Reiheneinbaugeraete_Baureihe_14_Planungshilfe_und_Betriebsanleitung_dt.pdf)
Gruß, Norbert
Ich habs mal kurz ausprobiert: Wenn der FTS14EM als Richtungstaster konfiguriert ist sendet z.B Eingang +E1 B0 und +E2 setzt BI.
Gruß, Norbert
Hallo,
ich tue mich noch etwas schwer mit dem per USB angeschlossenen FAM 14. Vor allen irritiert mich immer noch das
"unknown command" (siehe Bild).
Habe dann versucht, den FMS61NP als dezentralen Aktor über das FAM 14 anzusteuern. Aber das gelingt mir nicht. Auch wenn ich als Basisadresse 00000000 annehme und für den FMS61NP mit subDef eine aus dem Adressbereich des FAMs konfigurieren.
Ich kann zwar die Bestätigungstelegramme über das FAM14 empfangen, aber senden kann ich nicht. Dazu brauche ich wahrscheinlich doch noch das FTS14-FA oder das USB-GW. Sonst muss ich mit meinen Schaltbefehlen wohl im RS485-BUS bleiben.
Jemand eine Idee?
Christian
NACHTRAG:
habe nur versucht das FSR14-4x anzulernen. Das klappt zwar, aber ich bekomme es nicht angesteuert.
define EnO_switch_00001001 EnOcean 00001001
attr EnO_switch_00001001 IODev FAM14
attr EnO_switch_00001001 gwCmd switching
attr EnO_switch_00001001 room EnOcean
attr EnO_switch_00001001 subDef 00001001
attr EnO_switch_00001001 subType gateway
define SchalterAktion notify EnO_switch_00001010:BI set EnO_switch_00001001 on
Um Nachrichten aus dem RS485-Bus ins Funknetz abzusetzen braucht es ein FTD14 welches die Befehle dann unter eigenen Adressen weitersendet.
Über FAM14 oder FGW14 kann man keine Nachrichten in den Enocean Funk senden.
Ist hier gut erklärt: http://forum.fhem.de/index.php/topic,22635.0.html (http://forum.fhem.de/index.php/topic,22635.0.html)
Grüße, Norbert
Nachtrag zum FSR14:
Du musst den Aktor mit seiner tatsächlichen ID im RS485 Bus definieren welche Du mit PCT14 oder über den FAM14 in den FSR14 eingelern hast (4x).
Mit subdef definierst Du Deine Absender-ID für FHEM - irgendeine virtuelle Adresse.
Ich habe dazu nur ein anderes Phänomen (?) beobachtet welches ich hier http://forum.fhem.de/index.php/topic,22635.msg205200.html#msg205200 (http://forum.fhem.de/index.php/topic,22635.msg205200.html#msg205200) beschrieben habe. Würde mich freuen wenn jemand einen Hinweis dazu hat.
Grüße, Norbert
Hallo,
ZitatDu musst den Aktor mit seiner tatsächlichen ID im RS485 Bus definieren welche Du mit PCT14 oder über den FAM14 in den FSR14 eingelern hast (4x).
Mit subdef definierst Du Deine Absender-ID für FHEM - irgendeine virtuelle Adresse.
Danke! Das hat geklappt. Allerdings verstehe ich noch nicht, wie ich das EM dazu bringe, den Aktor auch wieder auszuschalten. wenn ich an den Eingang ein Signal anlege, sendet er mir ein "pressed" "BI" und wenn ich das Signal wegnehme ein "released" das "BO" fehlt mir..
ZitatUm Nachrichten aus dem RS485-Bus ins Funknetz abzusetzen braucht es ein FTD14 welches die Befehle dann unter eigenen Adressen weitersendet.
OK. Dann brauche ich wohl ein FTD 14. Verstanden.
Danke und Gruß,
Spartacus
Guten Abend,
An welchen Eingang legst Du ein Signal an? Der FSR14 hat doch gar keine Eingänge.
Gruß, Norbert
Er meint das EM-Modul, nicht den FSR. Ein Eingang des EM scheint sich exakt wie eine Tastaktion eines FT55 zu verhalten. Dort wird je nach Taste+Richtung ein A0, B0, AI ODER BI + released (beim Loslassen) gesendet. Will man mit einem notify o.ä. auf das Loslassen warten, so verwendet man am besten eine Sequence aus der gewünschten Taste+released Event. Wie man das wiederum beim EM löst, wo die Kontakte auch länger geschlossen sein können, weiß ich nicht. Hier müsste man ja konkret differenzieren, zu welchem expliziten Kanal das released gehört. KA, ob das vllt irgendwie im Telegramm mitgeschickt wird? Wenn nicht, fiele mir als Lösung ein, für jeden Reed-Kontakt zwei Tastereingänge i.S. einer NC/NO-Schaltung zu nutzen.
Sorry, hatte ich übersehen.
Man kann das EM Modul als Universaltaster oder Richtungstaster konfigurieren. Davon hängt es ab wie die Eingänge auf ID's gemappt werden. Ab Seite 9 hier gut erklärt:
www.eltako.com/fileadmin/downloads/de/_bedienung/RS485-Bus-Reiheneinbaugeraete_Baureihe_14_Planungshilfe_und_Betriebsanleitung_dt.pdf (http://www.eltako.com/fileadmin/downloads/de/_bedienung/RS485-Bus-Reiheneinbaugeraete_Baureihe_14_Planungshilfe_und_Betriebsanleitung_dt.pdf)
Ich benötige in meiner Anwendung nicht die Abfrage auf 'released'. Müsste aber funktionieren da direkt dem Kanal zugeordnet. Ich kann das aber Ende der Woche mal ausprobieren falls bis dahin noch keine Lösung vorliegt.
Gruß, Norbert
Hallo zusammen,
ich habe das jetzt erst einmal so gemacht:
define SchalterAktion notify EnO_switch_00001010:buttons.*pressed set EnOcean_switch_FSR14 on-for-timer 20
attr SchalterAktion room EnOcean
Warum wird eigentlich 2 x released gesendet?
2014-10-06 16:47:32 EnOcean EnO_switch_00001010 buttons: pressed
2014-10-06 16:47:32 EnOcean EnO_switch_00001010 channelB: BI
2014-10-06 16:47:32 EnOcean EnO_switch_00001010 BI
2014-10-06 16:47:33 EnOcean EnO_switch_00001010 buttons: released
2014-10-06 16:47:33 EnOcean EnO_switch_00001010 buttons: released
Beim FT55 passiert das auch!
Zumindest kann ich damit die "Treppenhauslicht"-Funktion realisieren. Das EM-Modul steht bei mir auf UT!.
Ziel soll es jetzt sein, zwei Eingänge des EMs zu nutzen, um den Aktor zu schalten.
1. Eingang: Reed-Kontakt an der Haustür ("pressed" = "Tür zu", "released" = "Tür auf")
2. Eingang: Lichtschranke mit open Collector ("pressed" = "Licht unterbrochen"; "released" = "Leerlauf")
Wenn sich an einem der beiden Eingänge der Status ändert (Reed: "pressed"-> "released"; LS: "released"->"pressed") schaltet die Beleuchtung an der Eingangstür für x-Sekunden ein.
Problem ist noch:
Wenn die Tür zu lange auf steht ("released") oder jemand etwas in die LS stellt ("pressed") soll nach 10min. eine Warnung per Mail verschickt werden und das Licht soll aus gehen. Das soll irgendwie mit dem watchdog-Modul funktionieren..
Christian
Spartacus
Zitat von: Spartacus am 06 Oktober 2014, 17:07:47
Warum wird eigentlich 2 x released gesendet?
Beim FT55 passiert das auch!
Beim FT55 passiert das (bei mir) nur dann, wenn nicht das korrekte model ("FT55") als Attribut gesetzt ist. Möglicherweise könnte man für das FTS14EM-Device ebenfalls einfach dieses model setzen und wäre das Problem dann los.
Zitat von: Spartacus am 06 Oktober 2014, 17:07:47
Problem ist noch:
Wenn die Tür zu lange auf steht ("released") oder jemand etwas in die LS stellt ("pressed") soll nach 10min. eine Warnung per Mail verschickt werden und das Licht soll aus gehen. Das soll irgendwie mit dem watchdog-Modul funktionieren..
Müsste es nach der commandref eigentlich auch - eigentlich müsste man dann nur als Event 1 eben im Falle der geöffneten Tür das "released" wählen und als Event 2 "pressed", dann müsste der Watchdog entsprechend nach z.B. 10 Minuten triggern, wenn pressed ausbleibt.
Hallo,
das mit dem FT55 habe ich mal eigestellt. Das funktioniert beim Taster auch, beim FTS14EM hat das keinen Effekt.
Das mit dem Watchdog hat funktioniert, allerdings wird nicht korrekt nachgetriggert. Ich versuche das gerade mit DOIF...
Spartacus
Hallo,
mit der Funktionalität des FTS14EM am FAM14 bin ich noch nicht zufrieden und deshalb möchte ich noch einmal in die Rude fragen, ob Euch ähnliche Phänomene mit dem GW bzw. einem FTS-FA bekannt sind:
Habe lt. eltako Anleitung die Enable und Hold-Klemme mit der Hold-Klemme, des FAM14 verbunden. Von Zeit zu Zeit kommt es dennoch vor, dass der Eingang am EM auf BI hängen bleibt, obwohl kein Signal anliegt. Erst beim erneuten Antriggern signalisiert fhem mir ein "release".
Das hat natürlich zur Folge, dass die Ansteuerung der Aktoren im BUS nicht korrekt verarbeitet wird..
An welchen Schrauben kann ich noch drehen, um das Problem in den Griff zu kriegen? Hat jemand eine Idee?
Das FAM14 steht auf Auto=1 und BA=2.
Danke und Gruß,
Spartacus
Probier mal beim FAM14 die BA 4 aus, damit werden zyklisch auch Statustelegramme der Busaktoren abgefragt, möglicherweise wird dann auch vom FTS14EM der Status erneut abgefragt und ggf. korrigiert, wenn ein Telegramm vorher verloren gegangen ist.
Hallo,
ich habe jetzt noch diverse Einstellungen probiert. BA=4 BA=5. Das hilf alles nichts! Die Verarbeitung bleibt unzuverlässig.
Teilweise wird auch der Aktor nicht geschaltet.
Ich habe derzeit zwei r-Pis im Einsatz:
an dem enocean pi sind alle Bus-Aktoren eingelernt. ganz normal über das enocean Modul. Die Ansteuerung funktioniert sauber.
an dem anderen pi, der über USB am FAM 14 hängt, ist ein Kanal des BUS-Aktors FSR14-4x eingelernt, und alle 10 Kanäle des EM. Zum Testen benutze ich aktuell nur Kanal 10.
Hier noch einmal die Ansteuerung auf dem USB-gekoppelten pi:
FAM 14:
define FAM14 TCM ESP2 /dev/ttyUSB0@57600
attr FAM14 comType RS485
attr FAM14 learningMode demand
attr FAM14 room EnOcean
attr FAM14 sendInterval 25
attr FAM14 verbose 3
FSR14-4x:
define EnOcean_switch_FSR14 EnOcean xxxx7284
attr EnOcean_switch_FSR14 IODev FAM14
attr EnOcean_switch_FSR14 alias Lampe
attr EnOcean_switch_FSR14 group Hauseingang
attr EnOcean_switch_FSR14 gwCmd switching
attr EnOcean_switch_FSR14 icon light_outdoor
attr EnOcean_switch_FSR14 manufID 00D
attr EnOcean_switch_FSR14 room EnOcean
attr EnOcean_switch_FSR14 subType gateway
FTS14-EM-Eingang 10
define EnO_switch_00001010 EnOcean 00001010
attr EnO_switch_00001010 IODev FAM14
attr EnO_switch_00001010 alias Lichtschranke
attr EnO_switch_00001010 group Hauseingang
attr EnO_switch_00001010 icon IR
attr EnO_switch_00001010 manufID 00D
attr EnO_switch_00001010 model FT55
attr EnO_switch_00001010 room EnOcean
attr EnO_switch_00001010 subType switch
DOIF Bedingungen für das Einschalten des Lichtes:
define LichtAn DOIF ([EnO_switch_00001010:buttons] eq "pressed")(set EnOcean_switch_FSR14 on) DOELSEIF ([EnO_switch_00001010:buttons] eq "released") (set EnOcean_switch_FSR14 off)
attr LichtAn room EnOcean
attr LichtAn wait 0:10
#
# Notabschaltung nach 60 Sekunden
#
define di_Benachrichtigung DOIF ([EnO_switch_00001010:buttons] eq "pressed") (set EnOcean_switch_FSR14 off)
attr di_Benachrichtigung room EnOcean
attr di_Benachrichtigung wait 60
Vielleicht fällt ja irgendjemandem noch etwas auf. Man kann sagen, von 10 Ansteuerungen funktioniert es 8 x korrekt.
Entweder der Eingang bleibt auf "BI" oder der Ausgang schaltet nicht.
Ohne pi kann ich die Schaltung nicht realisieren (also EM direkt am Bus-Aktor einlernen), da die Lampe ja zeitverzögert ausgeschaltet wird. Falls jemand eine andere Idee hat, wie ich meine Lichtschranke und den Reed-Kontakt auswerten kann (soll schon mit enocean realisiert werden), dann wäre ich dankbar für einen Tipp.
Gruß,
Spartacus.
Gruß,
Spartacus.
Hallo,
Hat hier niemand eine Idee, was man hier anders/besser machen könnte? Hat jemand ggf. das FTS14-FA in Verbindung mit dem FTS14-EM im Einsatz? Läuft das möglicherweise stabiler als den pi am FAM14 zu betreiben, oder werden auch Telegramme verschluckt...
Christian.
Hallo Christian,
Ich hatte eine solche Konfiguration mal zusammengestöpselt aber nicht im Dauerbetrieb getestet. Habe auch keine tiefgreifenden Kenntnisse über FHEM und Enocean und kann daher nur ein paar Ideen äußern:
- sendInterval ist laut Doku standardmäßig auf 100ms - mal getestet?
- USB Schnittstellenprobleme - traten bei mir an einem Cubietruck auf (checksum error bis hin zum disconnect auf Unix Ebene)
Grüße, Norbert
Hallo Norbert,
danke für Dein Feedback!
sendinterval habe ich schon heruntergesetzt auf 25ms. Das bringt leider auch nichts. Habe es jetzt noch mal auf "0" gesetzt.
Einen disconnect am USB kann ich nicht feststellen.
Ich habe jetzt m.E. noch zwei Möglichkeiten hier weiter zu kommen:
1. den pi von Grunde auf neu installieren und nur enocean drüber laufen lassen
2. ein FTS14-FA kaufen und hoffen, dass die Telegramme über das enocean pi-Modul besser ankommen.
ich fange mal mit Punkt 1 an!
Christian.
Hallo,
ich betreibe auch ein Eltako RS485 System in Verbindung mit Fhem.
Nun kommen die ersten dezentralen Aktoren dazu, und ich bin mir nicht sicher welche Sendeeinheit ich von Eltako verwenden soll, wie z.B. den FTS14-FA oder den FTD14.
Wo genau liegen hier die Unterschiede Vor- und Nachteile?
Den USB300 Stick habe ich bereits getestet, bin aber hier mit der Sendeleistung nicht zufrieden.
Vielen Dank...
Mit freundlichen Gruß
Hallo zusammen,
es würde mich auch Interessieren welcher der beiden Eltako Funksender besser für fhem Anwendungen sind.
Ich möchte darüber Enocen Steckdosen von Eltako ansteuern.
Aus den Datenblättern von Eltako kann ich nicht herausfinden welchen ich dafür nehmen kann (FTS14-FA oder FTD14).
Funkt schon jemand über einen dieser Funkmodulen??
Bin über den FGW14-USB mit dem Bus verbunden.
Gru & THX
Porsti
Du brauchst FAM14 und FTD14.
Siehe hier: http://forum.fhem.de/index.php?topic=22635.0 (http://forum.fhem.de/index.php?topic=22635.0)
Gruß, Norbert
Zitat von: Spartacus am 10 Oktober 2014, 13:55:28
Hallo,
ich habe jetzt noch diverse Einstellungen probiert. BA=4 BA=5. Das hilf alles nichts! Die Verarbeitung bleibt unzuverlässig.
Teilweise wird auch der Aktor nicht geschaltet.
Ich habe derzeit zwei r-Pis im Einsatz:
an dem enocean pi sind alle Bus-Aktoren eingelernt. ganz normal über das enocean Modul. Die Ansteuerung funktioniert sauber.
an dem anderen pi, der über USB am FAM 14 hängt, ist ein Kanal des BUS-Aktors FSR14-4x eingelernt, und alle 10 Kanäle des EM. Zum Testen benutze ich aktuell nur Kanal 10.
Hier noch einmal die Ansteuerung auf dem USB-gekoppelten pi:
FAM 14:
define FAM14 TCM ESP2 /dev/ttyUSB0@57600
attr FAM14 comType RS485
attr FAM14 learningMode demand
attr FAM14 room EnOcean
attr FAM14 sendInterval 25
attr FAM14 verbose 3
FSR14-4x:
define EnOcean_switch_FSR14 EnOcean xxxx7284
attr EnOcean_switch_FSR14 IODev FAM14
attr EnOcean_switch_FSR14 alias Lampe
attr EnOcean_switch_FSR14 group Hauseingang
attr EnOcean_switch_FSR14 gwCmd switching
attr EnOcean_switch_FSR14 icon light_outdoor
attr EnOcean_switch_FSR14 manufID 00D
attr EnOcean_switch_FSR14 room EnOcean
attr EnOcean_switch_FSR14 subType gateway
FTS14-EM-Eingang 10
define EnO_switch_00001010 EnOcean 00001010
attr EnO_switch_00001010 IODev FAM14
attr EnO_switch_00001010 alias Lichtschranke
attr EnO_switch_00001010 group Hauseingang
attr EnO_switch_00001010 icon IR
attr EnO_switch_00001010 manufID 00D
attr EnO_switch_00001010 model FT55
attr EnO_switch_00001010 room EnOcean
attr EnO_switch_00001010 subType switch
DOIF Bedingungen für das Einschalten des Lichtes:
define LichtAn DOIF ([EnO_switch_00001010:buttons] eq "pressed")(set EnOcean_switch_FSR14 on) DOELSEIF ([EnO_switch_00001010:buttons] eq "released") (set EnOcean_switch_FSR14 off)
attr LichtAn room EnOcean
attr LichtAn wait 0:10
#
# Notabschaltung nach 60 Sekunden
#
define di_Benachrichtigung DOIF ([EnO_switch_00001010:buttons] eq "pressed") (set EnOcean_switch_FSR14 off)
attr di_Benachrichtigung room EnOcean
attr di_Benachrichtigung wait 60
Vielleicht fällt ja irgendjemandem noch etwas auf. Man kann sagen, von 10 Ansteuerungen funktioniert es 8 x korrekt.
Entweder der Eingang bleibt auf "BI" oder der Ausgang schaltet nicht.
Ohne pi kann ich die Schaltung nicht realisieren (also EM direkt am Bus-Aktor einlernen), da die Lampe ja zeitverzögert ausgeschaltet wird. Falls jemand eine andere Idee hat, wie ich meine Lichtschranke und den Reed-Kontakt auswerten kann (soll schon mit enocean realisiert werden), dann wäre ich dankbar für einen Tipp.
Gruß,
Spartacus.
Gruß,
Spartacus.
Gibt es zur Anbindung des FTS14-EM einen finalen Stand? Ich stehe ebenfalls kurz davor dieses Device in Fhem einzubinden und habe nicht viel bzw. nichts im Wiki oder in der Commandref finden können.
Gruß, Sascha
Ich setze das FTS14-EM im Moment nur zu Anbindung des Klingeltasters ein, kann also zur Zuverlässigkeit nicht so viel sagen. Bisher hat es aber immer geklingelt, wenn jemand gedrückt hat ;). Die Einbindung ist sehr einfach - FHEM legt für jeden Kontakt, der betätigt wurde, automatisch ein eigenes Device an, welches sich im Prinzip wie ein FT55-Taster o.ä. verhält, man kann dann auf BI usw. triggern.
inwischen habe ich den FST14 auch eingebunden. War kein Problem.
Ich habe ihn allerdings mit dem Attribut model "FTS12" angelegt. Hierbei wechselt dann das Reading state zwischen "B0" (gedrückt) und "released" (nicht gedrückt) und nicht wie beim FT55 das Reading buttons zwischen "pressed" und "released" und state steht immer auf "B0".
Gruß, Sascha