Erfahrungsbericht

[tinyfhem]

In den letzten drei Monaten habe ich mich im Hobby-Modus mit Home Automation befasst und in diesem Zusammenhang auch mit FHEM. Als Bastelobjekt habe ich mir zunaechst das Eigenheim vorgenommen und insofern stand natuerlich erstmal das Thema Funk im Vordergrund. Im Neubau wuerde ich auf jedenfall ein drahtgebundenes Protokoll bevorzugen. Raspis gibt es im Haus schon einige, einen als DNS, DHCP, VPN server, zwei weitere als media streaming clients (OpenELEC, XBMC) und so war schnell ein weiterer aufgesetzt, nur fuer FHEM.

Mein erster Schritt war die Anschaffung eines EnOcean Pi. Ich hatte mich dabei von dem Gedanken leiten lassen, das Ding direkt auf die GPIO header zu stecken, es erschien mir auf dem Weg zumindest als die "kompaktere Loesung". Dass das Ding schlussendlich auch nur den serial port benutzt (und power), das war mir zu dem Zeitpunkt nicht klar. Mir war auch nicht bewusst, dass die EnOcean Technologie, z.B. in den Eltako Produkten umgesetzt, recht hoch im Preis sind. Ich hatte mich zwar auch etwas mit FS20 beschaeftigt und wusste sowohl, dass diese Produkte preiswerter sind, aber eben auch, dass Aktoren keine Quittungssignale senden und so landete ich eben erstmal auf EnOcean. Einen HMLAN Konfigurationsadapter habe ich mir zwar auch ins Regal gelegt, aber bisher noch nicht benutzt.

Als Starterkit fuer EnOcean habe ich mir das "Eltako Schaltaktor mit Funktaster BPS #30000014" zugelgt. Das Kit besteht aus einem FSR61 Schaltaktor und einem FT55 Funktaster und kostete 92 Euro. Ein heftiger Preis, wie ich finde.

Nun ging es daran, diese beiden Teile ueber FHEM zu benutzen. Mit dem Schaltaktor wollte ich ein "analoges Eltako Schaltrelais" ersetzen, d.h. in eine  vorhandene Anlage einbauen, die mit 4 fest verbauten elektrischen Tastern arbeitet und das wollte ich auch so beibehalten und eben zusaetzlich noch die Moeglichkeit schaffen, per Funktaster ueber FHEM zu schalten und zwar nicht nur um ortsungebunden einen weiteren Taster zu haben, sondern auch um komplexere Szenarien abbilden zu koennen, z.B. die entsprechende Lampe zu bestimmten Zeiten an oder aus zu schalten oder auch in Verbindung mit anderen Geraeten zu schalten. Aus diesem Grund brauchte ich einen Schaltaktor mit drei wesentlichen Funktionen (1) trigger ueber elektrisches Signal von den konventionellen Tastern (2) Funkansteuerung und (3) senden von Statusaenderungen per Funk. Letzteres ist vor allem deshalb wichtig, weil ja sonst FHEM nicht mitbekommt, wenn ein elektrischer Taster den Aktor schaltet.

Ein direktes anlernen des Funkasters an den Aktor kam fuer mich nicht in Frage. Ich wollte mit allem was ich mache, immer den indirekten Weg ueber FHEM gehen, wollte z.B. auch in der Lage sein, spaeter zu entscheiden, ob fuer meine Aufgabenstellung ein FS20 Taster ausreicht um den teuren Eltako Aktor zu schalten und genau soweit bin ich inzwischen auch aber dazu spaeter mehr.

Die Anfaenge mit FHEM sind mir nicht leicht gefallen. Natuerlich hatte ich das FHEM Wiki gelesen, natuerlich die FHEM reference, die im uebrigen in der Englischen Version deutlich mehr hergibt als in der Deutschen, was keine Kritik sein soll, nur eine Feststellung und auch ein Rat fuer andere Neulinge. Ich habe auch angefangen, hier im Forum entsprechende Threads zu lesen und postete auch meine kleinen Problemchen und ich bekam sehr konstruktive Antworten, dennoch, lernen musste ich natuerlich selbst und zwar durch viel probieren, was geht und was geht nicht.

Zunaechst beschaeftigte ich mich damit, wie ich den Aktor, den Taster und entsprechende event notifications konfigurieren konnte, so dass sich das ganze so verhielt, wie ich es wollte. Natuerlich hatte ich "autocreate" eingeschaltet und es entstanden auch entsprechende Definitionen sowohl fuer den Aktor als auch fuer den Taster. Selbige waren jedoch unvollstaendig und in der Form auch nicht wirklich brauchbar. Erst ueber posten der Fragestellung mit Auszuegen aus meiner config brachten mir richtungsweisende Hinweise, an denen ich aber noch viel Zeit brauchte bis es wirklich so funktionierte, wie ich es wollte. Dabei war mein Szenario ein recht einfaches. Ich hatte den Aktor selbst so programmiert, dass er nichts weitet tut, als auf ON und OFF Telegramme zu reagieren. Sollte ich mich entscheiden, dass ich eine Toggle Funktion brauchte, so musste das ueber FHEM zu realisieren sein und nicht durch Umkonfiguration des Aktors denn selbiger ist laengst Unterputz in einer Dose verschwunden, die ich nur dann oeffnen will, wenn der Aktor aufgrund eines Defektes ausgetauscht werden muss.

Erstmal musste der Funktaster verstanden werden. Das Geraet hat eine grosse Schaltwippe durch Druck nach oben, und durch Druck nach unten, ausgeloest werden kann. Wenn man die Wippe abbaut sieht man, dass darunter mechanisch vier Elemente ausgeloest werden koennen, dass bei der von mir verbauten Variante jedoch nur zwei nutzbar sind. Das verbaute EnOcean Modul (PTM 215) hat offenbar zwei Kanaele "channelA" und "channelB", die im einen Fall "A0" und "AI", im anderen Fall "B0" und "BI" Zustaende einnehmen koennen. Fuer mich war nur channelB verwendbar denn die eine grosse Schaltwippe war mechanisch so gestaltet, dass nur die B0/BI Klappen betaetigt werden koennen. Man koennte problemlos eine Doppelwippe einbauen, auf dem EnOcean module ist mechanisch alles dafuer vorgesehen, ich wuerde mich nicht wundern, wenn das entsprechende Eltako Produkt deutlich teurer sein wuerde.

Nachdem ich einige Zeit gebraucht hatte, bis ein Druck auf die B0 seite den Aktor EIN, und ein Druck auf die BI Seite den Aktor AUS schaltete, wollte ich optimieren und den Aktor im Toggle Modus schalten und somit mit dem Taster zwei unterschiedliche Aktoren schalten.

Ich bin bei folgender Konfiguration gelandet:

Code Auswählen Erweitern


#---------------------------------
# Eltako FSR61   
#---------------------------------
define actuator1 EnOcean  0187970B
attr   actuator1 IODev    TCM310
attr   actuator1 manufID  00D
attr   actuator1 model    FSR61
attr   actuator1 subDef   FF9AAE81
attr   actuator1 subType  switch
attr   actuator1 room     Living Room
attr   actuator1 group    0 Living Room


"manufID" und "model" habe ich abgeschrieben aus anderen Beispielen, die hier im Forum gepostet waren. Ich habe nirgends eine detailierte Beschreibung gefunden. Spannend war auch noch die Definition des "subDef", dazu musste man durch lesen des fhem log erstmal herausfinden, dass der EnOcean Pi transceiver als "TCM TCM310 BaseID=FF9AAE80" im System bekannt war und dass die ueber diesen transceiver anzusteuernden Elemente, ausgehend von dieser Basis, jeweils mit einer um 1 inkrementierten ID adressierbar gemacht werden muessen. Das "group" Konzept habe ich auch erst nach geraumer Zeit eingefuehrt, nachdem ich bemerkt hatte, dass auf der Weboberflaeche sonst alles nach Krauf und Rueben sortiert war. das "0 Living Room" hat deshalb eine "0" vorne, damit die Elemente dieser group gleich ganz oben platziert werden, denn FHEM sortiert hier alphanumerisch.

Nun zum Funktaster:

Code Auswählen Erweitern


#---------------------------------
# Eltako FT55
# Has an EnOcean PTM215 Module built in. This module supports 4 switches A0/AI, B0/BI.
# Only one pair is mechanically activated.
#---------------------------------
define switch1 EnOcean FEFF2D58
attr   switch1 IODev TCM310
attr   switch1 model FT55
attr   switch1 subType switch
attr   switch1 room Living Room
attr   switch1 group 0 Living Room


Was hier auffaellt ist, dass hier offenbar kein "manufID" gesetzt werden muss, ich weiss hier und jetzt auch nicht was passiert, wenn ich aus der Definition des Aktors das "manufID"  wieder ausbaue.  Ich werde mir wohl am besten bei Gelegenheit mal den source code des EnOcean moduls durchlesen muessen um genauer zu verstehen, wie diese attributes genau wirken und welche davon ueberhaupt ausgewertet und unterstuetzt werden.

Nun kommen wir zu den auszuloesenden Aktionen. Im ersten nofify soll nur der "B0" event von switch1 ausgewertet werden und abhaengig zum momentanen Zustand von actuator1 derselbe getoggled werden:

Code Auswählen Erweitern


define nswitch1B0 notify switch1:B0 { \
    if    (ReadingsVal("actuator1","channelB","") eq "BI") {fhem "set actuator1 B0"}   \
    elsif (ReadingsVal("actuator1","channelB","") eq "B0") {fhem "set actuator1 BI"} ;;\
}


Passend dazu die notification fuer den "BI" event, der in diesem Fall ein Element einer Energenie Steckdosenleiste schaltet, fuer die direkt ein "toggle" implementiert ist, es also nicht von Hand wie oben ausprogrammiert werden muss:

Code Auswählen Erweitern


define nswitch1BI notify switch1:BI set s1 toggle


Mit den bis hierher gezeigten Konfigurationsbeispielen funktioniert das geplante Szenario wie gewuenscht, mit einer Ausnahme: Die Schaltung tat nur in n aus m Versuchen, wobei "n/m" zwischen 0.6 und 0.8 war. Durch langes rumprobieren in der FHEM config, ohne deterministischen Erfolg, war ich irgendwann soweit, den FT55 auseinander zu nehmen und von hand die Kontakte und den Ausloeser zu druecken und siehe da, es funktionierte dann in "n/m = 1" Faellen. Offenbar ist die Wippenkonstruktion mit den beiden kleinen Plastiknasen, die die Schaltelemente nieder druecken sollen, nicht wirklich ausgereift implementiert. Ich habe durch entsprechend unterlegte Papierstreifchen dieses Problem fuer den Moment basteltechnisch geloest und nun funktioniert die Schaltung auch ueber die aufgesetzte Wippe sauber. Laengere Zeit hatte ich auch an der Zuverlaessigkeit bzw Reichweite der Funkstrecke gezweifelt obgleich alle Elemente zum Schluss nicht mehr weiter als 5m voneinander entfernt waren.

Nun war es Zeit, weitere Elemente in die Anlage einzubauen. Zunaechst ging es um schaltbare Steckdosen und dafuer habe ich mich fuer die "EnerGenie EG-PM2-LAN, programmierbare 6-fach IP-Steckdosenleiste, LAN-Schnittstelle" entschieden und ich habe diese Entscheidung bisher nicht bereut. Die Einbindung in FHEM war supereasy, kein Vergleich zu dem bisher erfahrenen mit den EnOcean Teilen. Bestimmt war es auch deshalb leichter, weil ich inzwischen mehr Erfahrungen mit FHEM gesammelt hatte, dazu kommt aber sicher auch, dass hier keinerlei Funk im Spiel ist, zumindest solange nicht, solange man die Elemente ueber die Weboberflaeche schaltet.

Als naechste Uebung habe ich eine dieser Steckdosen ueber den noch freien "Kontakt" des FT55 geschaltet, dafuer war ein einziges notify zu definieren, wie bereits oben gelistet:

Code Auswählen Erweitern


define nswitch1BI notify switch1:BI set s1 toggle


Hier in diesem Beispiel ist "s1" eine der vier Steckdosen einer Energenie, die wie folgt definiert ist:

Code Auswählen Erweitern


#---------------------------------
# Server Room

define pstrip1 EGPM2LAN pstrip1.xxxxx.net 1
attr   pstrip1 room Server Room


Dann die einzelnen Dosen:

Code Auswählen Erweitern


define s1    EGPM pstrip1 1
attr   s1    room Server Room

define fox   EGPM pstrip1 2
attr   fox   room Server Room

define gnu   EGPM pstrip1 3
attr   gnu   room Server Room

define esxi  EGPM pstrip1 4
attr   esxi  room Server Room


Jetzt war ich soweit, nach kostenguenstigeren Loesungen zu suchen und nun kam FS20 ins Spiel. Als erstes habe ich mir bei busware.de ein CUL 868 mit der billigen Drahtantenne bestellt und mit der V3 Firmware geflashed. Schnell war das Teil per autocreate in FHEM bekannt und auch der "6-Tasten-Aufputz-Wandsender FS20S6A, Bausatz" von ELV war ruck zuck zusammengeloetet und funktionierte auf Anhieb. Den FS20S6A habe ich so eingestellt, dass jeder der 6 Tasten ein separates toggle erzeugt. Als naechsten Versuch, habe ich mit einer dieser Tasten dann die bereits ueber den EnOcean FT55 angesteuerten Aktor angesteuert:

Code Auswählen Erweitern


define nFS20_4c0b00 notify FS20_4c0b00 { \
    sleep 0.7 ;; \
    if    (Value("actuator1") eq "off") {fhem "set actuator1 on"}     \
    elsif (Value("actuator1") eq "on")  {fhem "set actuator1 off"} ;; \


Da ich noch weitere Taster "uebrig" hatte, habe ich noch folgende Variante probiert:

Code Auswählen Erweitern


define nFS20_4c0b02 notify FS20_4c0b02 { \
    sleep 0.5 ;; \
    if    (ReadingsVal("actuator1","channelB","") eq "BI") {fhem "set actuator1 B0"}    \
    elsif (ReadingsVal("actuator1","channelB","") eq "B0") {fhem "set actuator1 BI"} ;; \
}


Beide Varianten funktionieren, allerdings die zuerst gelistete nur dann, wenn die Definition von actuator1 noch um eine eventMap wie folgt erweitert wurde:

Code Auswählen Erweitern


attr   actuator1 eventMap BI:off B0:on


Da noch weiter FS20 Taster frei waren, auch noch die Uebung, die Energenie Steckdose uebe den FS20 zu schalten:

Code Auswählen Erweitern


define nFS20_4c0b01 notify FS20_4c0b01 set s1 $EVENT


Damit liess sich die Steckdose auf Anhieb sehr zuverlaessig schalten.

Ueber die FS20 Taster habe ich allerdings fuer das bereits oben beschrieben "n/m < 1" Problem keine wirklich zuverlaessige Loesung gefunden. Hier ueber das Forum wurde meine Vermutung bestaetigt, dass sich die beiden Funkprotokolle, FS20 und EnOcean ueberlagern und gegenseitig stoeren koennen, deshalb in beiden oben gezeigten Varianten jeweils ein "sleep". Mit den genauen Zeiten, irgendwo zwischen 0.3 und 0.7 Sekunden, experimentiere ich noch aber richtig 100% zuverlaessig ist das ganze noch nicht. Mit dem FT55 ist das besser, jedenfalls nach meinem mechanischen "Fix" (siehe oben).

Nun brauchte ich noch eine Loesung fuer die Situation, wo eine 6-port Energenie zu aufwendig war. Es sollte auch noch ein einzelnes Geraet, in diesem Fall die Kaffeemaschine geschaltet werden, hier war die Aufgabenstellung so, dass selbige 5 Minuten, nachdem sie eingeschaltet wurde, automatisch abgeschaltet wird denn es war an der Tagesordnung, dass das ausschalten immer wieder "vergessen" wurde.

Also einen Satz "Elro AB440S/3C" bestellt, mit dem Wissen, dass das "IT" module die Frequenz des CUL 868 auf 433 Mhz bei Bedarf ein und spaeter wieder zurueck stellen wuerde. Die Konfiguration der Dosen war auch schnell erledigt, ich Liste hier mal exemplarisch nur eine:

Code Auswählen Erweitern


#---------------------------------
# ELRO Switches
#---------------------------------
define ELRO_A IT    000F00FFFF FF F0
attr   ELRO_A alias Coffeemaker
attr   ELRO_A IODev CUL_0
attr   ELRO_A model itswitch
attr   ELRO_A room  Kitchen

#---------------------------------
# Turn off Coffeemaker after 5 min
define nELRO_Aon  notify ELRO_A:on  define ELRO_Aoff at +00:05:00 set ELRO_A off
define nELRO_Aoff notify ELRO_A:off delete ELRO_Aoff


Und dann noch diverse Ansteuermoeglichkeiten, man kann das jetzt ueber den EnOcean FT55 Taster oder einen der FS20 Taster machen, fuer den FS20 Taster sieht das bei mir im Moment wie folgt aus:

Code Auswählen Erweitern


define nFS20_4c0b03 notify FS20_4c0b03 { \
    sleep 0.5 ;; \
    if    (Value("ELRO_A") eq "off") {fhem "set ELRO_A on"}    \
    elsif (Value("ELRO_A") eq "on") {fhem "set ELRO_A off"} ;; \
}


Funktioniert. Allerdings ist auch hier "n/m < 1" und zwar deutlich. Hier ist meine Vermutung die, dass das CUL 868 mit seiner fuer 868Mhz abgestimmten L/4 Antenne einfach nicht weit genug kommt. Aus diesem Grund habe ich nun auch ein separates CUL 433 mit der dazu passenden Antenne bestellt und versuche dann herauszufinden, ob das ganze zuverlaessiger laeuft. Mit dem aktuellen setup, ueber das CUL 868 kann ich bisher auch keine Telegramme, z.B. von der Originalfernbedienung der ELROs empfangen. Ich erhoffe mir, dass das mit dem CUL 433 dann moeglich sein wird und ich somit die Zustaende der Steckdosen in FHEM aktualisieren kann, wenn man die Originalfernbedienung benutzt. Wie das dann geht, muss ich erst noch heraus finden.

Last not least habe ich noch eine weitere Bastelstunde spendiert denn die Klingel im Haus ist nur im EG zu hoeren, nicht aber im UG und im OG. Also habe ich mir den FS20 KSE Bausatz bestellt, zusammengebaut und einfach parallel an die Klingel geklemmt. Wenn nun jemand auf die Klingel drueckt, geht ein FS20 Telegramm an FHEM, das ich im Moment wie folgt auswerte:

Code Auswählen Erweitern


#---------------------------------
# FS20 KSE (Klingelsignal Erkennung)
#---------------------------------
define FS20_c08000 FS20 c080 00
attr   FS20_c08000 alias Bell
attr   FS20_c08000 event-min-interval .*:15
attr   FS20_c08000 IODev CUL_0
attr   FS20_c08000 room  Living Room
attr   FS20_c08000 group 0 Living Room

define nFS20_c08000 notify FS20_c08000 "echo Subject: Ring | /usr/sbin/ssmtp -f xxxx@@yyyyyy.zzz xxxx@@yyyyyy.zzz"


Funktioniert auch hinreichend zuverlaessig und ich bekomme nun, egal wo ich bin, per push notification einen Einzeiler als Mail aufs Smartphone. Die Verzoegerung ist im Normalfall kleiner als 3 Sekunden, garantieren kann man das jedoch nicht. In einer spaeteren Variante, moechte ich bei eintreffen des Telegramms von der FS20 KSE ueber eine Raspi Infrarot cam ein still foto schiessen und selbiges gleich als attachment an die email klemmen, damit ich gleich weiss, wer draussen steht. Eine noch bessere Variante waere dann, gleich ueber das Smartphone ein Live Bild zu bekommen und eine Gegensprechanlage zu haben, dann natuerlich noch der Tueroeffner dazu .... Fuer dieses Szenario gibt es natuerlich fertige Loesungen, aber die sind sehr teuer, das geht bestimmt mit dem FHEM setup, den ich bereits habe, mit preisguenstigen Erweiterungen.

Nun noch ein paar abschliessende Bemerkungen / Erfahrungen: Ich bin sehr angetan von FHEM. Es ist eine sehr gut gemachte Integrationsplattform um mehrere Standards / Protokolle und deren Elemente zu integrieren.  Vielen vielen Dank an die Entwickler des Gesamtframeworks und natuerlich auch der einzelnen Module. Mir wurde hier auf dem Forum bei jeder gestellten Frage geholfen, auch dafuer recht herzlichen Dank an die User, die immer wieder gerne ihre Erfahrungen weiter zu geben bereit sind. Selbiges moechte ich hier mit diesem Beitrag auch tun.

Einzig mag ich es nicht so sehr, dass FHEM mir die cfg file optisch verhunzt. Man kann darueber sicher lange diskutieren, warum das sinnvoll ist, dass FHEM die exclusive Kontrolle ueber diese file hat. Ich jedenfalls bin das aus der Unix Welt anders gewohnt, da wird ein .conf file manuell erstellt und gepflegt und das auswertende Programm liest dieses .conf file ausschliesslich. Ich brauche eine bestimmte Formatierung dadrin, zur besseren Lesbarkeit, ausserdem halte ich die config unter Versionskontrolle, in meinem Fall checke ich das Ding regelmaessig in ein simples RCS repository ein. Ich handhabe es wie folgt: Vor jeder Aktion, die FHEM veranlasen KOENNTE, die cfg zu schreiben, erstelle ich ein backup und trage dann nach erfolgter Veraenderung durch FHEM, z.B. im Falle eines autocreate von neuen devices, die Aenderung manuell in mein backup ein und mache selbiges dann wieder zum Original. Fuer mich waere das voelllig ok, dass FHEM die cfg file selbst schreibt, aber nur dann, wenn mein layout / format beibehalten wuerde. Da ich den dafuer noetigen Programmieraufwand mich noch nichtmal traue vorzuschlagen, mache ich es so, wie eben beschrieben. Wie das dann aussieht, kann man in den "code" Beispielen in diesem Beitrag sehen. Ich habe noch keine finale Entscheidung getroffen, wie ich das cfg file schlussendlich strukturiere, ob ich alles "per room" organisiere oder "per technology", also alles was EnOcen ist in eine section (oder gar include file) schreibe gefolgt von allem was FS20 ist .... Es waere fuer mich auch keine Loesung, wenn FHEM anfangen wuerde, die Konfiguration in einer SQL database zu pflegen, im Gegenteil, das waere fuer mich, und all die, die ebenfalls die config von Hand pflegen, ein gewaltiger Rueckschritt. Ich moechte in der Lage sein, mit dem Editor meiner Wahl die Konfiguration zu erstellen und zu pflegen, Elemente durch copy/paste herzustellen.

Ueber Diskussion und Anregungen ueber das hier dargestellte, wuerde ich mich freuen. Bestimmt kann man das eine oder andere noch wesentlich eleganter oder zuverlaessiger machen. Am meisten bin ich natuerlich an einem "n/m = 1" interessiert und das ist bisher nicht ueberall der Fall.

Mir haette als Anfaenger ein derartiger Erfahrungsbericht sehr geholfen, denn es ist bei weitem nicht alles aus der FHEM Reference, dem FHEM Wiki zu entnehmen. Falls dieser Bericht besser in "Anfaegerfragen" (obgleich es ja eher keine Fragen sind) untergebracht ist, so mag er gerne dorthin verschoben werden. Man koennte auch diskutieren, ob es sinnvoll waere, die einzelnen Szenarien zu zerlegen und dann szenariobezogen jeweils einen Thread unter "Codeschnipsel" aufzumachen?. Jedenfalls ist ein Teil meiner Motivation fuer diesen Schrieb, dass er anderen Anfaengern den Einstieg erleichtern moege.

[betateilchen]

Einzig mag ich es nicht so sehr, dass FHEM mir die cfg file optisch verhunzt. Man kann darueber sicher lange diskutieren, warum das sinnvoll ist, dass FHEM die exclusive Kontrolle ueber diese file hat.

Diese Diskussion ist müssig, bereits mehrfach geführt und immer mit dem gleichen Schluss ausgegangen: Es gibt keinen wirklich nachvollziehbaren Grund, warum man sich um die Optik der Konfigurationsdatei kümmern müsste.

Ich brauche eine bestimmte Formatierung dadrin, zur besseren Lesbarkeit

Niemand muss überhaupt jemals in der fhem.cfg lesen - man kann die gesamte Konfiguration über das Frontend durchführen.

Die von Dir beschriebene Versionierung bekommst Du übrigens automatisch, wenn Du anstatt mit den Konfigfiles mit einer SQL Datenbank zu diesem Zweck arbeitest - einschließlich einer DIFF Funktion, die Dir Unterschiede in Gerätedefinitionen zwischen verschiedenen Versionen darstellt.

Ich komme jedenfalls perfekt ohne jegliche Konfigurationstextdatei für fhem klar.

[tinyfhem]

Nun sind fast vier Wochen rum, seit diesem Erfahrungsbericht und ich habe einige weitere Erfahrungen gesammelt, die ich hier berichten moechte, auch in der Hoffnung, durch feedback weiteres dazu zu lernen.

Was mich aktuell am meisten beschaeftigt ist die Zuverlaessigkeit der Schaltung oder besser gesagt das fehlen derselben. Bisher habe ich ja nur sehr einfache Schaltungen aufgebaut, unter Verwendung von EnOcean, HomeMatic, FS20, Intertechno, und Gembird Energenie Powerstrips. Im Raspi stecken zu dem Zweck je ein 868 und ein 433 MHz CUL in den USB ports, ein EnOcean Pi auf dem GPIO Header und ein HMLAN Adapter steckt im LAN. Dier Raspi mit den trancseivern, der HMLAN Adapter und saemtliche Sensoren und Aktoren befinden sich auf demselben Stockwerk und die Entfernung auf den Funkstrecken ist in allen Faellen zwischen 3m und 10m. Von den Energenies befindet sich eine einen Stock tiefer, die andere einen Stock hoeher, was kein Problem sein sollte, denn die werden sowieso nicht ueber Funkprotokolle angesprochen. Die Schaltung ist komplett indirekt, d.h. kein Sensor ist auf einen Aktor direkt angelernt, es ist immer FHEM dazwischen.

Nun meine Erfahrungen:

• Die Gembird Energenies vergessen nach einem Stromausfall ihre Konfiguration, nach dem wiedereinschalten sind sie von FHEM nicht mehr erreichbar und die Zustaende der vier ports entsprechen nicht denen wie vor dem Stromausfall. Inzwischen betreiebe ich die Energenies mit Werkseinstellungen, dann koennen sie auch nichts mehr vergessen aber befriedigend ist diese Loesung nicht. Ich experimentiere zur Zeit mit einer dritten Energenie, die nicht ueber FHEM gesteuert wird, um herauszufinden, wie sich die Energenies verhalten, wenn man sie vom Netz nimmt und nach unterschiedlichen Zeitintervallen wieder einsteckt. Wichtig ist mir, dass sie dann erstens die ports in denselben state schalten, in dem sie vor dem Stromausfall waren, und zweitens dass sie mindestens 5min versuchen per DHCP eine IP Adresse zu bekommen, denn der DHCP server waere ja im Falle des echten Stromausfalls auch down und braeuchte eine gewisse Zeit zum booten, 5min erscheinen mir da angemessen.
• Die Intertechno Dosen (ELRO) sind defakto unbrauchbar, jedenfalls in Umgebungen, wo man wirklich sicher sein will, dass ein Schaltbefehl auch ausgefuehrt wurde. FHEM bekommt von diesen Dosen keine Rueckmeldung. Ich unterscheide hier zwischen "Quittungstelegramm" und der Moeglichkeit einer Statusabfrage (set xxxx statusRequest). Bei den ELRO Dosen und vermutlich allem anderen was Intertechno spricht, geht weder das eine noch das andere. Mir ist klar, dass das kein Fehler ist sondern ein "works as designed". Nur ist das halt so in mission critical environments nicht einsetzbar, als Bastelloesung mag das durchaus in Frage kommen
• EnOcean. Auf diese Komponenten kam ich "damals" als erstes, weil ich einen Aktor suchte, in ein vorhandenes Stromstossrelais ersetzen konnte und weiterhin ueber elektrische Taster schaltbar sein sollte. Damit das geht, muss der Aktor bei durch die elektrischen Taster ausgeloesten Zustandsaenderungen, Funktelegramme schicken, die von FHEM ausgewertet werden und den state des Objekts nachziehen und dann auch spaeter  komplexere Operationen auf diesem state ausfuehren zu koennen. EnOcean schickt solche Funktelegramme und die Schaltungen funktionieren auch prinzipiell, aber alles andere als zuverlaessig. Ein Anwendungszenario ist das Schalten einer Lampe, die an einem FSR61 (EnOcean, Eltako) haengt und als Sensor wird ein FS20 Funktaster verwendet. Ich habe bisher kein einziges mal die Situation gehabt, dass FHEM ein Telegramm vom FS20 Taster nicht gesehen haette. Ich kann allerdings nicht zweifelsfrei aus FHEM's logs heraus lesen, dass FHEM auch in jedem Fall einen Schaltbefehl an den FSR61 schickte. Das einzige was ich zweifelsfrei sehen kann ist dass die Lampe nicht angeht und zwar in 40% bis 50% der Versuche und das ist selbstverstaendlich unbrauchbar und ich verstehe bisher nicht warum das so ist. Ich hatte hier in einem anderen thread vor einiger Zeit die Frage gestellt, ob sich die Funkprotokolle gegenseitig beeinflussen, also das vom FS20 Taster gesendete mit dem von FHEM zum Aktor gesendeten kollidiert und das wurde mir dann bestaetigt und die Empfehlung war, im notify ein "sleep 0.3" einzubauen. Das gabe ich getan aber es hat die Zuveralessigkeit der Schaltung, wenn ueberhaupt, dann nur unwesentlich verbessert. Es ist im uebrigen kein grosser Unterschied ob ich hie ein Signal von einem EnOcean Taster auswerte oder ein Signal von einem FS20 Taster. Gestern hatte ich ein Szenario, da war die Lampe aus und der FS20 Taster wurde genau 4 mal in Abstand von ca 2s gedrueckt., das haette eine AN, AUS, AN, AUS Sequenz geben muessen, am Schluss war die Lampe an statt aus und FHEM war der Meinung sie sei aus. Beim Untersuchen dieses Zustands fiel es mir dann auf, dass das schicken eines Quittungstelegramms die eine Sache ist, aber die Faehigkeit abgefragt zu werden und einen Status zu liefern (set <object> statusRequest) eine andere. EnOcean kann offensichtlich letzteres nicht HomeMatic jedoch schon. Gerade in Umgebungen, in denen die Schaltung offensichtlich sowieso nicht zuverlaessig arbeitet, ist es wichtig, wenigstens die Moeglichkeit zu haben ein set <object> statusRequest zu haben. Hier und jetzt bin ich auf dem Trip, keinerlei weiteren EnOcean Komponenten zu verbauen und stattdessen mit HomeMatic weiter zu experimentieren aber kommen wir nun zu HomeMatic:
• HomeMatic kam bei mir zuletzt in die Experimentierumgebung. Habe inzwischen 2 x HM-LC-SW2-FM und 3 x HM-LC-SW1-FM in Betrieb. Grundsaetzlich liegen mir diese Aktoren deutlich besser als die EnOcean/Eltako FSR61. beim FSR61 ist das Anlernen deutlich komplizierter als bei den HomeMatic Teilen. Man muss Potis in Linksanschlag und Rechtsanschlag drehen und stufen bzw rasenlose Stellungen dieser Potis finden um bestimmtes Betriebsverhalten einzustellen, das gefaellt mir ganz und gar nicht, vor allem schon deshalb nicht, weil ich bei Aenderung dieses Verhaltens das Objekt wieder aus der UP Dose hervor fummeln muss. Bei HomeMatic ist das deutlich einfacher. Da ich sowieso in jedem bisher verbauten Fall mindestens einen elektrischen Taster habe um den Aktor anzusteuern, kann ich auch im verbauten Fall, durch 5 Sekunden druecken des Tasters den Aktor in den Anlernzustand bringen, ohne in der UP Dose rumfummeln zu muessen. Auch das Anlernen selbst ist einfacher und ich bekomme ausser on,off, on-for-timer bei HomeMatic auch noch einen toggle, beim EnOcean habe ich nur on, off, on-for-timer aber kein toggle und muss deshalb ein toggle im FHEM emulieren. Aber zurueck zu HomeMatic: Auch hier funktionieren meine Schaltungen nur zuverlaessig, wenn die Aktoren ueber die elektrischen Taster betaetigt werden. Bei der Schaltung meiner Kaffeemaschine ist ein HomeMatic Aktor in der UP Dose hinter der Steckdose verbaut, es ist dabei kein elektrischer Taster im Spiel, ich kann also im eingebauten Zustand diesen Aktor weder resetten noch neu anlernen doch genau das wurde erfoderlich denn nach nur wenigen Schaltzyklen loggte FHEM folgendes:

Code Auswählen Erweitern


2014-04-27_13:20:32 CoffeeMaker set_on-for-timer 300
2014-04-27_13:20:32 CoffeeMaker level: 100
2014-04-27_13:20:32 CoffeeMaker pct: 100
2014-04-27_13:20:32 CoffeeMaker deviceMsg: on (to HOMA1)
2014-04-27_13:20:32 CoffeeMaker on
2014-04-27_13:20:32 CoffeeMaker timedOn: running
2014-04-27_13:20:37 CoffeeMaker set_off
2014-04-27_13:20:53 CoffeeMaker ResndFail
2014-04-27_13:20:53 CoffeeMaker MISSING ACK
2014-04-27_13:22:07 CoffeeMaker set_off
2014-04-27_13:22:24 CoffeeMaker ResndFail
2014-04-27_13:22:24 CoffeeMaker MISSING ACK
2014-04-27_13:23:07 CoffeeMaker ResndFail
2014-04-27_13:23:07 CoffeeMaker MISSING ACK
2014-04-27_13:23:58 CoffeeMaker set_off
2014-04-27_13:24:14 CoffeeMaker ResndFail
2014-04-27_13:24:14 CoffeeMaker MISSING ACK
2014-04-27_13:25:46 CoffeeMaker powerOn: -
2014-04-27_13:25:46 CoffeeMaker level: 0
2014-04-27_13:25:46 CoffeeMaker pct: 0
2014-04-27_13:25:46 CoffeeMaker off
2014-04-27_13:25:46 CoffeeMaker timedOn: off
2014-04-27_13:26:09 CoffeeMaker ResndFail
2014-04-27_13:26:09 CoffeeMaker RESPONSE TIMEOUT:RegisterRead
2014-04-27_13:27:23 CoffeeMaker set_reset
2014-04-27_13:27:40 CoffeeMaker ResndFail
2014-04-27_13:27:40 CoffeeMaker MISSING ACK


• 
  Wie man in dem Log sehen kann, hat es in diesem Zustand dann auch nicht mehr geholfen, den Leitungsschutzschalter abzuschalten und nach 90s wieder einzuschalten. Der Aktor war nicht mehr zu bewegen, auf commands zu antworten. Dass er richtig gepaired war, kann man sehen, denn er schickte die Quittung auf das "set on-for-timer 300" an: "2014-04-27_13:20:32 CoffeeMaker deviceMsg: on (to HOMA1)". Schlussendlich habe ich den Aktor aus der Anlage wieder ausgebaut und einen anderen gleichen Typs verbaut, selbiger hat nun seit 4/27 "funktioniert", allerdings haengt er auch noch vor der Dose gewissermassen an den Draehten und ist nicht in der UP Dose verbaut. Ich kann noch nicht sagen, ob er auch weiterhin funktioniert, wenn er in der Dose ist und die Steckdose davor geschraubt wird. Ich habe auch in weiteren Schaltungen, bei denen z.B. der zweikanal HomeMatic Aktor (HM-LC-SW2-FM) in der Verteilung angebracht ist die Situation gehabt, dass ResndFail / MISSING ACK kamen, selbiges kann man dann im WebUI an der grauen Lampe mit dem roten Fragezeichen drin erkennen. Also hier und jetzt auch bei HomeMatic alles andere als Zuverlaessigkeit. Den fehlerhaften Aktor habe ich inzwischen auf dem Labortisch in Betrieb, habe ihn resetted und neu angelernt und nun funktioniert er, obgleich er sogar einen Stock tiefer liegt als der FHEM-Raspi mit seinen Transceivern, also der Fehler ist nicht reproduzierbar und das Teil offenbar nicht exemplarisch defekt.
• FS20 KSE. Hie kann ich nur sagen, die Klingelsignalerkennung und Weiterverarbeitung funktioniert fehlerfrei. Inzwischen schicke ich mir nicht mehr selbst eine Mail aufs Smartphone, wie oben im Teil-1 gezeigt, sondern habe auf "Pushover" umgebaut, funktioniert 1a.

Ich habe bei den Bastelarbeiten viel gelernt. Zum einen ueber die Leistungsmerkmale der verschiedenen Komponenten, zum anderen ueber FHEM und wie man damit debugged. Bei den Leistungsmerkmalen sortiere ich nun EnOcean wesentlich weiter unten ein als noch zu Anfang, weil es einfach keine "set <object> statusRequest" versteht. Also ist zur Zeit Homematic bei mir ganz oben auf der Liste, allerdings zuverlaessig ist es bisher auch leider absolut nicht. Die Schaltung muss bei 100 klicks auf die Taster 50 mal das Pattern ON-OFF ausfuehren denn genau das tut eine 30 Jahre alte Schaltung mit einem konventionellen Stromstossrelais. FHEM muss in diesem Szenario den Zustand des Objekts 100 mal aendern und er muss zu jedem Zeitpunkt der Realitaet entsprechen. Ich erwarte hierbei nicht, dass jemand den Taster mit einer hoeheren Frequenz als 0.5Hz drueckt.

Beim debuggen mit FHEM hatte ich zunaechst im wesentlichen den Event Monitor im Web UI benutzt denn beim "inform" in der telnet session fehlten mir die timestamps. Inzwischen laeuft bei mir immer ein "tail -f /opt/fhem/log/fhem-2014-05.log" mit und ich passe den loglevel entsprechend dem zu debuggenden Problem an. Was ich hilfreich faende waere wenn eingehende und ausgehende messages durch ">" bzw "<" gekennzeichnet waeren, so haette man schneller einen Ueberblick ueber das ablaufende Protokoll aber das sind eher Kleinigkeiten. Ich kann hier und jetzt nicht sagen, dass auch nur irgendeines der beobachteten Unzuverlaessigkeiten an FHEM liegt, vielmehr befuerchte ich, dass mit egal welchem Funkprotokoll grundsaetzlich keine zuverlaessige Schaltung hinzubekommen ist. Im Neubau wuerde ich in jedem Fall drahtgebundene Kommunikation waehlen.

Wie sind denn eure Erfahrungen? Erwarte ich zuviel, z.B. in dem Szenario: "100 mal klick auf den Taster soll 50 ON-OFF Sequenzen erzeugen"? GIbt es jemand, bei dem derartige Schaltungen ueber Funkprotokolle in dieser Liga mitspielen koennen? Wenn ja, dann wuerde ich gerne weiter untersuchen wollen, woran es in meinen Schaltungen liegt. Die entsprechenden FHEM Definitionen zeige ich dann gerne, den relevanten Teil davon habe ich eh oben in Teil-1 bereits gepostet, mit Ausnahme der HomeMatic Teile, die hatte ich vor vier Wochen noch nicht in Betrieb. Ist das mischen von Protokollen problematisch? Also die Idee einen FS20 Taster zu nehmen um einen HomeMatic Aktor zu schalten? Ist hierbei damit zu rechnen, dass sich die verschiedenen Funkprotokolle stoeren? Ist der Raspi grundsaetzlich das richtige Geraet fuer FHEM? Sollte ich mal die USB Dongles in einen "richtigen" PC stecken und das ganze damit testen?

[Rince]

Ist der RasPi das richtige Gerät für fhem?
Ja und nein.
Besser als ne FritzBox
Schlechter als ein Cubieirgendwas oder ein BeagleBoneBlack

Wenn du nicht fit in Linux bist, bietet er wohl unzweifelhaft im Moment die größte Fan/Unterstützungsgemeinde.

Ein ausgewachsener PC braucht halt Strom.


Zuverlässigkeit von HM:
Ja, nicht unspannend.
Habe derer im Moment ca. 8 Taster im Einsatz.
1 Dimmer hat den Dienst eingestellt (defekt)
1 Taster hat dermaßen schlechte Klemmen, das ein Kabel nach dem Einbau in die UP Dose nach einiger Zeit immer wieder raus geht.

Aber, nichts desto weniger, für Funk mit Rückmeldung kenne ich nichts anderes in der Preisklasse.
Daher bleibe ich bei HM.
Vor allem ist auch toll, die vorhandenen Schaltprogramme weiter nutzen zu können.

Intertechno setze ich in einem Raum ein. Zuverlässigkeit ist grenzwertig. Damit will man nicht wirklich oft schalten
In unserer neuen Wohnung werde ich einige IT Steckdosen verwenden, da dort docht recht viele LED Leuchtketten verbastelt sind, die dringend automatisiert werden müssen

Allerdings ziehe ich demnächst um.

[UliM]

Hi,
sehr interessant, vielen Dank für Deinen ausführlichen Bericht.

Bezgl Deiner Problemstellung "Stromstossrelais" nutze ich hier seit ca 1 Jahr einen HM-LC-SW1-FM, wird von einem FS20-Bewegungsmelder via fhem oder über Hardware-Taster (Stromstoss) eingeschaltet, über fhem-timer wieder aus. Funktioniert absolut zuverlässig.

Die von Dir beschriebene Unzuverlässigkeit der Schaktvorgänge kann ich für meine Installation (zum Glück) nicht bestätigen. Ich hab nen Haufen FS20/FHT/S300TH über nen CUL plus wenige HM-Komponenten über HMLAN im Einsatz.  Daher schließe ich mich Deiner Vermutung an, dass sich die Telegramme der unterschiedlichen Transceiver überlagern soweit sie im selben Frequenzband funken - bei Dir also EnOcean, FS20 und HM. Wäre spannend dazu Rudis oder Boris' Meinung zu hören.

Hast Du mal probeweise EnOcean deaktiviert und getestet, wie sich die Zuverlässigkeit FS20/HM dadurch entwickelt?

Auf jeden Fall weiterhin viel Erfolg und viele Späße,
Uli

[Puschel74]

Hallo,

zu FS20/HM.

Ich habe meine Geräte geschätzt auf 50:50 auf FS20 und HM aufgeteilt.
OK es sind noch nicht "so viele" aber ich habe weder mit FS20/FHT noch mit HM Probleme - zum Glück.
Ich schalte meine HM-Aktoren mit FS20-Sensoren.

Grüße

[rudolfkoenig]

UliM hat mich gebeten, hier was zu sagen, ich kommentiere das, was mir auffaellt, bzw. wozu ich was sagen kann:

- falls Dir fhem.cfg heilig ist, dann verwende keine Komponenten die automatisch was anlegen (wird nicht ganz trivial sein), und auch keine Attribute/etc direkt in FHEM aendern. rereadcfg empfehle ich auch nicht, am besten shutdown/restart, und save ist Tabu. Das ist zwar nicht meine Praeferenz (mir ist egal, wie fhem.cfg aussieht), wird aber von FHEM unterstuetzt, man kann mit diese Methode auch include verwenden. Was zu Problemen (bzw. unzufriedene Benutzer) fuehrt ist beide Methoden (edit & save) zu mischen.

- wg mehreren Protokollen: es gibt in der Tat noch kein Mechanismus in FHEM, unterschiedlichge Protokolle so zu behandeln, dass die sich nicht gegenseitig stoeren. Es gibt zwar ein "sendpool" fuer CUL, das ist aber nur fuer FS20 gedacht. Sowas Protokolluebergreifend waere wuenschenswert. Um es konkreter zu sagen: Es ist ein Problem, auf einmal Befehle fuer Aktoren unterschiedlicher Protokolle zu senden. Es ist kein Problem von Sender A (Protokoll 1) was zu empfangen, und damit Aktor B (Protokoll 2) zu schalten.

- wg. Rueckmeldung: ich finde es nicht sehr nuetzlich zu wissen, das irgendetwas nicht geklappt hat, viel wichtiger ist mir, dass es klappt. HM sendet ein Telegramm bei fehlenden ACK bis zu zweimal hinterher (in der Summe also dreimal), FS20 sendet immer dreimal. Bei meinen FS20 Geraeten funktioniert das Schalten von FHEM gefuehlt zu 98%, die restlichen 2% stoeren mich nicht wirklich. Ich habe aber immer wieder drangedacht, in culfw fuer FS20 Collision-Detection auch fuer FS20 zu aktivieren (fuer RFR wird es bereits verwendet), bisher fehlt mir die Musse dazu.

[rudolfkoenig]

Es ist kein Problem von Sender A (Protokoll 1) was zu empfangen, und damit Aktor B (Protokoll 2) zu schalten.

Korrektur: selbst das kann ein Problem sein: wenn bei FS20 schon die erste Nachricht korrekt empfangen wurde, und daraufhin FHEM z.Bsp. einen HM Aktor schalten will, dann wird das HM Befehl losgeschickt, waehrend der FS20 Sender noch seine Wiederholungen sendet.

[C_Herrmann]

Hallo,

dann wäre es doch zu empfehlen, ein sleep() entsprechend der Länge der Signaldauer vor dem auszusendenden Befehl einzufügen, wenn ein Gerät mit einem System (z.B. FS20) gesendet und einem anderen (z.B. HM) empfangen wird. Sollten beide über das gleiche IO-Device (z.B. FS20 und IT) angesprochen werden, ist das nicht erforderlich.

Dazu müsste sleep aber auf Time::HiRes umgestellt werden. Jetzt sind ja nur volle Sekunden möglich. Das wäre mE zu viel. Eine Verzögerung von 0,1 bis 0,3 Sekunden wären sicher tolerabel.

Gruß,
Christian

[tinyfhem]

Ist der RasPi das richtige Gerät für fhem?
Ja und nein.
Besser als ne FritzBox
Schlechter als ein Cubieirgendwas oder ein BeagleBoneBlack

Wenn du nicht fit in Linux bist, bietet er wohl unzweifelhaft im Moment die größte Fan/Unterstützungsgemeinde.

Ein ausgewachsener PC braucht halt Strom.

Bin ein Linuxer seit den ersten Stunden, mein erstes SuSE lief 1994. Also von daher gesehen werde ich auf einem Linux hosted FHEM bleiben, egal ob das nun ne Fritz ist oder ein Raspi. Klar, FHEM noch auf die sowieso laufende Fritz zu laden, waere vom Energieverbrauch sicherlich das oekonomischste aber ich wuerde gerne selbige untouched lassen, die 5W fuer einen fuer FHEM dedizierten Raspi wuerde ich mir goennen.

Aus keinem der bisher geposteten Antworten konnte ich schliessen, dass die performance des Raspi grenzwertig sein koennte, also schliesse ich den als Fehlerquelle bei mir mal aus.

Zuverlässigkeit von HM:
Ja, nicht unspannend.
Habe derer im Moment ca. 8 Taster im Einsatz.
1 Dimmer hat den Dienst eingestellt (defekt)
1 Taster hat dermaßen schlechte Klemmen, das ein Kabel nach dem Einbau in die UP Dose nach einiger Zeit immer wieder raus geht.

Aber, nichts desto weniger, für Funk mit Rückmeldung kenne ich nichts anderes in der Preisklasse.
Daher bleibe ich bei HM.
Vor allem ist auch toll, die vorhandenen Schaltprogramme weiter nutzen zu können.

Intertechno setze ich in einem Raum ein. Zuverlässigkeit ist grenzwertig. Damit will man nicht wirklich oft schalten
In unserer neuen Wohnung werde ich einige IT Steckdosen verwenden, da dort docht recht viele LED Leuchtketten verbastelt sind, die dringend automatisiert werden müssen

Allerdings ziehe ich demnächst um.

Du hast hier auf elektrische  / mechanische Zuverlaessigkeit der Komponenten fokussiert. Hast offenbar keine Probleme mit der Zuverlaessigkeit der Umsetzung der gesendeten Befehle. Bei mir ist es umgekehrt, bisher alle Komponenten elektrisch / mechanisch ok.

[tinyfhem]

Hi,
sehr interessant, vielen Dank für Deinen ausführlichen Bericht.

Bezgl Deiner Problemstellung "Stromstossrelais" nutze ich hier seit ca 1 Jahr einen HM-LC-SW1-FM, wird von einem FS20-Bewegungsmelder via fhem oder über Hardware-Taster (Stromstoss) eingeschaltet, über fhem-timer wieder aus. Funktioniert absolut zuverlässig.

Den  HM-LC-SW1-FM setze ich auch ein, das ist eigentlich genau der, von dem ich dann wenns mal in ein Produktivsystemn gehen wuerde, mehr einsetzen wuerde, wenn ich dann den Zustand erreicht habe, dass es die 98% Schaltsicherheit erreicht. Gut zu wissen, dass der Mischbetrieb FS20 / HM bei Dir zuverlaessig funktoiniert. Habe uebers Wochenende meinen ersten Bewegungsmelder bestellt, allerdings einen HM.

Die von Dir beschriebene Unzuverlässigkeit der Schaktvorgänge kann ich für meine Installation (zum Glück) nicht bestätigen. Ich hab nen Haufen FS20/FHT/S300TH über nen CUL plus wenige HM-Komponenten über HMLAN im Einsatz.  Daher schließe ich mich Deiner Vermutung an, dass sich die Telegramme der unterschiedlichen Transceiver überlagern soweit sie im selben Frequenzband funken - bei Dir also EnOcean, FS20 und HM. Wäre spannend dazu Rudis oder Boris' Meinung zu hören.

Also erstmal dachte ich ja, dass dieser Mischbetrieb FS20 Sensor / HM Aktor evtl. zu vermeiden ist aber von den Antworten hier in diesem Thread kann ich sehen, dass das durchaus ein Szenario ist, das einige einsetzen und das in der Regel sauber arbeitet. Zumindest haben sich drei oder vier von euch in der Richtung geaeussert und ausser mit hat noch keiner geschrieben, dass es nicht tut. Vielleicht ist also doch bei meiner config was faul aber die koennten wir ja dann ggf hier mal im Forum etwas detailierter anschauen.

Hast Du mal probeweise EnOcean deaktiviert und getestet, wie sich die Zuverlässigkeit FS20/HM dadurch entwickelt?

Das habe ich bisher noch nicht getan, werde ich aber noch tun. Bisher habe ich nur einen EnOcean Sender und einen EnOcean Aktor, letzterer ist zwar UP in einer Dose verbaut aber den kann ich noch problemlos durch einen HM Aktor ersetzen. Ich werde EnOcean mal komplett deaktivieren, also den transceiver aus FHEM rauskonfigurieren und elektrisch vom Pi runter ziehen und die entsprechenden Definitionen per "ignore" disablen und dann testn und hier wieder berichten.

[tinyfhem]

UliM hat mich gebeten, hier was zu sagen, ich kommentiere das, was mir auffaellt, bzw. wozu ich was sagen kann:

- falls Dir fhem.cfg heilig ist, dann verwende keine Komponenten die automatisch was anlegen (wird nicht ganz trivial sein), und auch keine Attribute/etc direkt in FHEM aendern. rereadcfg empfehle ich auch nicht, am besten shutdown/restart, und save ist Tabu. Das ist zwar nicht meine Praeferenz (mir ist egal, wie fhem.cfg aussieht), wird aber von FHEM unterstuetzt, man kann mit diese Methode auch include verwenden. Was zu Problemen (bzw. unzufriedene Benutzer) fuehrt ist beide Methoden (edit & save) zu mischen.

Also in dem Punkt bin ich lernfaehig. Ich komme zwar aus einer Welt, wo eine derartige .conf "die Source" ist, die mit vi editiert wird und dann der entsprechende consumer dieser conf zum reload veranlasst wird aber ich schaetze sehr wohl das Konzept von FHEM mit autocreate und aendern der config direkt uebers Web UI. Zur Zeit mache ich das so, dass ich per RCS Versionskontrolle der fhem.cfg mache. Die file gehoert root.root und hat 644 permission, d.h. FHEM kann da erstmal nicht reinschreiben. Wenn ich neue devices integrieren moechte, ziehe ich erst eine copy von fhem.cfg, mache dann ein chmod a+w auf fhem.cfg und lasse die neuen config Teile per autocreate erstellen. Anschliessend merge ich die neuen statements wieder in meine Original .cfg und mache sie dabei "lesbar" und bringe auch Kommentare ein. Ich habe keinerlei Probleme mit diesem Mischbetrieb, funktioniert alles bestens und ich lerne jeden Tag dazu, was und wie man Dinge auf dem Web UI machen kann. Z.B. habe ich nur ueber das Web UI dann exploratorisch rausgefunden, dass mein EnOcean Aktor ja gar kein "set <object> statusRequest" versteht. Ich kann mir durchaus vorstellen, dass ich auch noch soweit komme, dass mir die fhem.cfg nicht mehr wichtig ist. In dem Fall wuerde ich ggf auch gleich den Schritt gehen, die config in einer database zu halten, wie das manche ja bereits tun. Ich wuerde sagen, ich bin einfach noch nicht fortgeschritten genug. Ich denke allerdings nicht, dass meine Probleme mit der Zuverlaessigkeit der Schaltungen daher ruehren, dass ich die fhem.cfg manuell bearbeite. Ich selbige gerne hier auch mal vollstaendig posten.

- wg mehreren Protokollen: es gibt in der Tat noch kein Mechanismus in FHEM, unterschiedlichge Protokolle so zu behandeln, dass die sich nicht gegenseitig stoeren. Es gibt zwar ein "sendpool" fuer CUL, das ist aber nur fuer FS20 gedacht. Sowas Protokolluebergreifend waere wuenschenswert. Um es konkreter zu sagen: Es ist ein Problem, auf einmal Befehle fuer Aktoren unterschiedlicher Protokolle zu senden. Es ist kein Problem von Sender A (Protokoll 1) was zu empfangen, und damit Aktor B (Protokoll 2) zu schalten.

Ich glaube in das Szenario, gleichzeitig requests an Aktoren unterschiedlicher Protokolle zu senden, bin ich noch gar nicht gelaufen. Bisher ging es nur darum, von FS20 (oder EnOcean) Signale zu empfangen und daraus abgeleitet entweder einen EnOcean Aktor oder einen HM Aktor zu schalten aber niemals gleichzeitig.

- wg. Rueckmeldung: ich finde es nicht sehr nuetzlich zu wissen, das irgendetwas nicht geklappt hat, viel wichtiger ist mir, dass es klappt. HM sendet ein Telegramm bei fehlenden ACK bis zu zweimal hinterher (in der Summe also dreimal), FS20 sendet immer dreimal. Bei meinen FS20 Geraeten funktioniert das Schalten von FHEM gefuehlt zu 98%, die restlichen 2% stoeren mich nicht wirklich. Ich habe aber immer wieder drangedacht, in culfw fuer FS20 Collision-Detection auch fuer FS20 zu aktivieren (fuer RFR wird es bereits verwendet), bisher fehlt mir die Musse dazu.

Da bin ich mit Dir, die fehlenden 2% wuerden mich auch nicht stoeren. Fuer mich ist auch nachvollziehbar, dass ein Aktor, der einen Befehl eh nicht verstanden hat, weder ein ACK noch ein NACK schickt. Obwohl, wenn er etwas nur teilweise verstanden hat, aber nicht genau was, dann koennte er ja ein NACK schicken. Wichtiger ist, dass die zentrale Steuerung (FHEM) einen statusRequest machen kann und darauf dann eine sinnvolle Antwort bekommt. Zum einen kann FHEM bei Erhalt einer Antwort den internen state sauber darstellen, zum anderen kann FHEM bei ausbleibender Antwort dann in einer noch zu konfigurierenden Form reagieren, im Zweifelsfall per Pushover eine Nachricht an mein Smartphone schicken und mir mitteilen, dass irgendwas mit dem Garagentorantrieb nicht so funktioniert hat wie es sollte, das Tor ggf offen ist, obwoihl FHEM es schliessen wollte, aber FHEM nicht weiss ob es geschlossen wurde. Wobei der Garagentorantrieb bei mir ja noch gar nicht konfiguriert ist, es geht bisher nur um ein paar Lampen, dafuer wuerde ich den Pushover nicht brauchen aber solange die simplen Szenarios nicht tun, brauche ich mit den komplexeren noch gar nicht anfangen.

Ich habe bisher nicht beobachtet, dass FHEM ein Telegramm nicht empfangen hat. Vielmehr scheint es umgekehrt zu sein, dass Aktoren die von FHEM gesendeten Requests nicht umsetzen, kann es mir aber bisher ncht erklaeren, denn der Raspi mit den transceivern liegt auf der selben Etage wie Sensoren und Aktoren und die Enternungen sind alle wie gesagt zw. 3m und maximal 8m. Die Antennen sind eigentlich auch weit genug voneinander entfernt. der EnOcean steckt auf dem GPIO header, das 868MHz CUL fuer FS20 ist per USB Kabel ca 1m davon weg. der HMLAN ist 4m vom Raspi weg. Nur der 433MHz CUL steck direkt im Raspi USB, also in unmittelbarer Naehe des EnOcean Pi.

Ist denn der EnOcean Pi zuverlaessig? Er hat ja auch nur die Lambda/4 Drahtantenne. Uebrigens: Mein 868MHz CUL hat auch nur das Draehtchen. Da ich den 433er spaeter bestellte, als ich schon merkte, dass die Schaltung nicht zuverlaessig tat, habe ich die bessere, extern angeschlossene Antenne bestellt.

Ich koennte mal versuchen, die Anlage runter zu strippen, also mit ner leeren FHEM cfg anfangen und nur CUL 868 und HMLAN zu betreiben und nur einen FS20 Taster und einen HM Aktor. Selbige dann per autocreate definieren und eine ganz einfache ON / OFF Schaltung von FS20 nach HM zu testen und dann schauen, wie hoch die "Erfolgswahrscheinlichkeit ist.

Auf jeden Fall an dieser Stelle vielen Dank fuer die Antworten und Hinweise von allen, die bisher geantwortet haben.

[tinyfhem]

Update: Bzgl. der ELRO Steckdosen habe ich inzwischen neue Erfahrungen. Das Problem ist bei in meiner Konfiguration, dass die Teile von FHEM gesendete Befehle nach einiger Zeit einfach nicht mehr ausfuehren. Ich habe herausgefunden, wenn ich dann die Steckdose ziehe und ca 30s spaeter wieder in dieselbe oder auch eine andere Steckdose einsetze, dann reagieren sie wieder auf Befehle von FHEM. Ich habe noch nicht getestet, ob sie in dem Zustand, in dem sie von FHEM nicht mehr ansprechebar sind, ueber die mitgelfierte Fernbedienung noch reagieren. Man koennte fast meinen, in den Dingern waere ein kleiner Microcontroller, dessen firmware irgendwie in den Wald gelaufen ist und das Rausziehen und nach 30s wieder reinstecken, liesse die Dinger wieder booten und dann ist fuer eine bestimmte Zeit wieder alles ok. Hat jemand aehnliche Erfahrungen gemacht? Gibt es ausser den ELRO Dosen auch noch andere Dosen, die zum dem Intertechno Protokoll kompatibel sind, waere fuer eine Empfehlung dankbar.