Test Adapter EnOcean v0.3.x
-
Habe jetzt einfach mal den PR übernommen.
Gesendet von Unterwegs
-
Einen kleinen Fehler korrigiert, ansonsten läuft es soweit. Teste morgen noch die Rauchmelder.
Update : Rauchmelder getestet. Kleine Korrektur und jetzt laufen sie.
-
Hallo Zusammen,
Jetzt muss ich mich mal anmelden, da etwas passiert ist, womit ich nicht mehr gerechnet habe
Vielen Dank erst mal an Jey Cee und allen die sich hier mit einbringen.Ich selbst komme von FHEM und hoffe mich hier mit einbringen zu können.
Zumindest als Tester… :mrgreen:Da meine installation auf Enocean beruht, habe ich folgende Devices im Einsatz:
****NodOn EnOcean Schalter SIN-2-2-00
Datenblatt:
https://www.greenelectric.eu/content/no … active.pdf**** Cooles Device, da swowohl Actor als auch Taster. D.h. man kann einen physikalischen Taster anschliessen und das Device sendet die Schaltinfo.
supported EEP F6-02-01, F6-04-01, F6-10-00, D5-00-01, A5-07-01 -03, A5-08-01 -03 und A5-10-XX (XX= 01 05 08 0C 10 13 16 17 18 19 1A 1B 1C 1D) und A5-14-01 -04
bisher noch nicht getestet.
Eltako Funktaster, FT55-RW (PTM 215 ,4-Taster)
Datenblatt:
https://www.enocean.com/de/enocean_module/ptm-215/
supported EEP F6-02-xx, F6-04-xx sowie D2-03-00 für den secure Mode
getestet. Zustände werden von allen 4 Tastern erkannt.
Eltako Funkaktor, FUD61NPN - Universal-Dimmschalter
Datenblatt:
https://www.eltako.com/fileadmin/downlo … ow_res.pdf
supported EEP H5-38-08 (Info FHEM)
Eltako Funkaktor, FSB61NP - Rollladen und Beschattungselemente
Datenblatt:
https://www.eltako.com/fileadmin/downlo … ow_res.pdf
supported EEP G5-3F-7F ? (Info FHEM)
Das wars auch schon was ich testen kann. Klar Actoren erst wenn das Senden funktioniert.
-
Eine Überlegung, die wir uns stellen sollten:
Beim F6-02-XX gibts 3 (oder waren es 4) verschiedene Varianten, die zwar unterschiedlich interpretiert werden, aber letztendlich doch nur die Zustände der 4 Buttons A0, AI, B0, BI wiedergeben.
Ist es sinnvoll, alle unterschiedlichen Interpretationen der EEP zu implementieren oder reicht es, jeweils die allgemeine Form einzubauen? Letztendlich ist es mir in ioBroker ja egal, ob der Schalter mit I oben oder 0 oben an der Wand hängt, mich interessiert, welche Taste gedrückt wurde.
-
Man kann sich schon überlegen, ob man EEPs zusammenlegt. Bei den F6-02-xx gibt es z.B. den Unterschied, ob 2 oder 4 Tasten vorhanden sind (und die Enums sind unterschiedlich).
Aber F6-02-01 und F6-02-02 sind eigentlich identisch und könnten zusammengelegt werden.
-
Bei den F6-02-xx gibt es z.B. den Unterschied, ob 2 oder 4 Tasten vorhanden sind (und die Enums sind unterschiedlich). `
Laut https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwjslIew3__YAhWMK8AKHQ6tCwEQFggnMAA&url=https%3A%2F%2Fwww.enocean.com%2Ffileadmin%2Fredaktion%2Fenocean_alliance%2Fpdf%2FEnOcean_Equipment_Profiles_EEP_V2.6.3_public.pdf&usg=AOvVaw1HCMpW6jwz7GWJLtKhyIxX ist F6-02 für 2 Tasten und F6-03 für 4 Tasten, oder steh ich da auf dem Schlauch?!Der einzige Unterschied in den F6-02 Enums ist IMO, dass die Knöpfe einmal A1/B1 und sonst AI/BI heißen. Bei A1/B1 hab ich das Gefühl, da hat sich wer vertan. Und natürlich die unterschiedliche Interpretation je nach Unter-EEP, aber die ist IMO nur relevant für Geräte, die diese Daten direkt verarbeiten und umsetzen.
-
Sorry,
natürlich haben alle F6-02-xx 4 Tasten (2 Wippen). F6-02-03 und F6-02-04 haben nur eine andere Belegung der Bits.
Auch das gleichzeitige Drücken 2er Tasten ist bei F6-02-03 wohl nicht vorgesehen.
Da war ich wohl beim Schreiben etwas unkonzentriert
-
Kannst du für die Eltako Funkaktoren die Hex-Nachrichten per aktiviertem Debug aus dem Log zur Verfügung stellen?
Ich habe die Aktoren leider nicht und dann könnte man die Parser mit den aufgenommenen Nachrichten testen.
Sofern diese Rückmeldungen geben.
Ansonsten evtl. was aus FHEM?
-
natürlich haben alle F6-02-xx 4 Tasten (2 Wippen). F6-02-03 und F6-02-04 haben nur eine andere Belegung der Bits.
Auch das gleichzeitige Drücken 2er Tasten ist bei F6-02-03 wohl nicht vorgesehen. `
Und genau darauf zielt meine Frage ab. Ich würde das soweit wie möglich vereinheitlichen. Ob ich mehrere Tasten drücken kann und wie herum der Taster an der Wand hängt, sollte ioBroker egal sein. Das kann sich der User selbst überlegen, wie er die verwendet.Am Ende sollte mmn. nur der Zustand der Tasten A0/AI/B0/BI in ioBroker ankommen - und das bei allen F6-02-xx. Eine Unterscheidung zwischen A1 und AI wie es die Doku macht, würde ich sogar weglassen.
Was die anderen EEPs angeht, müsste man noch prüfen.
-
Btw. ich werde demnächst nochmal meinen Multisensor mit der neuen Version testen. Beim alten Code war hier noch Nacharbeit nötig.
-
Bei den F6-02-xx ist die Bedeutung aber nicht immer die Selbe.
F6-02-03 redet z.B. von "set the controller into automatic mode". Wenn man das weglassen würde, wäre es nur Taste A0.
Wobei mir noch nicht ganz klar ist, was "automatic mode" am Ende für ioBroker bedeuten würde.
Ich habe ja auch ein "keep alive" für die Rauchmelder eingeführt, und nicht die Tastennamen benutzt, obwohl der Rauchmelder auf F6-02-01 EEP beruht.
Ich würde hier über die einfachen Tastennamen hinaus gehen und die Funktionalität abbilden. Macht es, glaube ich, vielen Leuten einfacher. Das ist auch ein Grund, warum Jey Cee vorschlug, eine Auswahl nach Hersteller und Gerät vorzusehen.
Der "einfache" Nutzer braucht dann keine tiefergehenden Kenntnisse der EEPs.
-
Kannst du für die Eltako Funkaktoren die Hex-Nachrichten per aktiviertem Debug aus dem Log zur Verfügung stellen?
Ich habe die Aktoren leider nicht und dann könnte man die Parser mit den aufgenommenen Nachrichten testen. `
Kann ich gerne machen. Mal schauen ob ich sehe was die Aktoren zurück geben wenn eine Aktion ausgelöst wird.
Wird aber 1-2 Tage dauern. Zeit…
-
Bei den F6-02-xx ist die Bedeutung aber nicht immer die Selbe.
F6-02-03 redet z.B. von "set the controller into automatic mode". Wenn man das weglassen würde, wäre es nur Taste A0.
Wobei mir noch nicht ganz klar ist, was "automatic mode" am Ende für ioBroker bedeuten würde. `
Mir ist eben auch nicht klar, was die Interpretation (z.B. automatic mode) für ioBroker für einen Mehrwert hat. Oft ist es ja auch so, dass Leute ein Gerät missbrauchen wollen für was anderes. Siehe die Anfragen für die Tradfri-Fernbedienung als Universal-Remote.Ich denke wir sollten bei allen F6-02-xx die 4 Tasten bereitstellen, und das möglichst einheitlich.
Wenn ihr es als sinnvoll erachtet, könnte man die Interpretation, (z.b. on/off, dim+/dim-, etc.) on-top als zusätzliche DP anbieten.
Oder alternativ die "Interpretation" für den standardmäßigen common.name des DP benutzen? Dann haben User die Info, was die Taste machen soll, und wir duplizieren keine Funktionalität.
Ich habe ja auch ein "keep alive" für die Rauchmelder eingeführt, und nicht die Tastennamen benutzt, obwohl der Rauchmelder auf F6-02-01 EEP beruht. `
Du hast den Rauchmelder als …_smokedetector geführt, den Rest als ..._native. Die Unterscheidung könnte man IMO schon treffen.Mal abgesehen davon: Gibts für den Rauchmelder eigentlich keinen eigenen EEP?
Der "einfache" Nutzer braucht dann keine tiefergehenden Kenntnisse der EEPs. `
Ist in EnOcean nicht auch eine automatische Erkennung vorgesehen? FHEM hat das soweit ich weiß, zumindest die PTM215 werden im Teach-Modus erkannt. -
Der Rauchmelder von Eltako "beruht" auf F6-02-01, aber hat spezielle Aussagen (z.B. Rauchalarm, Keep-alive).
Eltako hat dafür keine eigene EEP ins Leben gerufen.
Der Hauptgrund, warum ich am ioBroker-Enocean-Adapter arbeite, ist, dass die speziellen Eigenheiten der Rauchmelder nicht berücksichtigt wurden. Wenn der einen Rauchalarm-Status hat und eine Keep-Alive-Funktion, dann sollten die richtig erkannte werden. Und ein Rauchmelder sollte schon andere Daten zur Verfügung stellen als ein Rollladentaster.
Und mit der automatischen Erkennung der vorher benutzen Enocean-Bibliothek hatte ich so meine Probleme. Die haben die Rauchmelder als F6-03-irgendwas erkannt und die liefen dann nicht wirklich.
Jee Cey möchte eine automatische Erkennung einbauen, wenn die gut funktioniert.
-
Der Hauptgrund, warum ich am ioBroker-Enocean-Adapter arbeite, ist, dass die speziellen Eigenheiten der Rauchmelder nicht berücksichtigt wurden. Wenn der einen Rauchalarm-Status hat und eine Keep-Alive-Funktion, dann sollten die richtig erkannte werden. Und ein Rauchmelder sollte schon andere Daten zur Verfügung stellen als ein Rollladentaster. `
Macht Sinn, keine Frage. -
Schön zu sehen das hier viel Diskutiert wird
Also Automatische Erkennung ja, als generisches Gerät und mit der Option ein Gerät aus einer Liste mit Vorschlägen aus zu wählen.
Damit wäre dann auch die Frage geklärt ob man möglichst allgemein oder sehr Spezifische Datenpunkte/Objekte bereitstellt.
Den Vorschlag common.name zu verwenden um "Alternative" Interpretation der Tasten dar zu stellen ist sehr interessant. Dadurch kann man ein Geräteprofil erstellen welches die Datenpunkte anhand des Generischen EEP Profils erstellt, aber die Namen kommen aus dem Geräteprofil.
Gesendet von Unterwegs
-
@Jey Cee:Also Automatische Erkennung ja, als generisches Gerät und mit der Option ein Gerät aus einer Liste mit Vorschlägen aus zu wählen. `
Gerade mal geschaut was die Konkurrenz macht: https://github.com/mhop/fhem-mirror/blo … an.pm#L856Die entscheiden bei Schaltern (F6) anhand den T21 und NU Bits welche sub-EEP (-02-, -03-, -10-) es ist und weisen die allgemeinste Form (-01 oder -00) zu. Ob das beim Smokesensor auch geht, ist die Frage.
Aber einen automatischen Vorschlag, den man noch editieren kann, fänd ich super.
-
Selbst wenn der Rauchmelder als F6-02-01 erkannt würde, würden die keep-alive als "keine Taste gedrückt" interpretiert werden, und der Alarm als Taste X.
Soweit mir bekannt, behandelt die Konkurrenz die Rauchmelder ebenfalls speziell.
Ein KeepAlive ist schon klasse. Die Auswretung mache ich noch über ein Skript, aber ein generischer Adapter für solche Geräte wäre klasse (oder im Enocean-Adapter). Die Rauchmelder melden sich alle 20Min mit einem Taster-Öffnen-Telegram. Das könnte man in den EEP-Definitionen hinterlegen und dann ein richtiges KeepAlive generieren.
Was haltet ihr davon, wenn wir solche Ideen als Issues auf Github eintragen. Dann vergessen wir das nicht und können stückweise anfangen, die geplanten Änderungen umzusetzen.
-
Nochwas: Ich hab gerade mal meinen Multisensor angeschlossen. Der ist ne Entwicklerversion und verwendet keine Standard-Telegramme. Um sowas zu unterstützen und Geräte mit EEPs, die wir noch nicht implementiert haben, hab ich nen kleinen PR gebastelt:
https://github.com/Jey-Cee/ioBroker.enocean/pull/15
> Was haltet ihr davon, wenn wir solche Ideen als Issues auf Github eintragen.
Dafür sind die da Also los!closed last detected id #15
-
+1
Gesendet von Unterwegs
