Hallo zusammen,
ich setze hier diverse Eltako TF61L Lichtaktoren mit Eltako Bewegungsmeldern ein, die im Tipp-Funk-Modus konfiguriert sind, konkret mit "halbautomatischer Bewegungserkennung", d.h. empfängt der Lichtaktor 5 Minuten keine "Bewegung" schaltet er aus. In den nächsten 5 Minuten schaltet er bei Bewegung wieder ein. Halbautomatisch deswegen, weil das nur passiert, wenn man initial manuell per Taster eingeschaltet hat.
Jetzt zur Problemstellung: Aufgrund der Örtlichkeiten habe ich nun an einer Stelle die Situation, dass ich bei einem Bewegungsmelder nicht auf den Tipp-Funk-Modus setzen kann. Da im selben Lichtaktor aber schon andere Bewegungsmelder eingelernt sind, würde ich ungern die komplette Logik nach FHEM verlagern, wenn es sich anders lösen ließe.
Wenn der Aktor über Fhem mit "on" angesteuert wird, greift die o.g. Rückfallverzögerung
nicht. Das ist auch gar nicht so schlecht, da ich so immer die Möglichkeit habe den Aktor in "Dauer-An" anzusteuern. Was ideal wäre, wenn ich den Aktor in FHEM als weiteres Subdef oder zusätzliches device betreiben könnte, mit dem ich das spezielle Tipp-Funk-Telegramm vom Bewegungsmelder (https://www.eltako.com/fileadmin/downloads/de/_bedienung/FBH55SB_30000514-1_dt.pdf) simulieren könnte, so dass die Rückfallverzögerung am Aktor greift:
ZitatTF-Modus-Datentelegramm nach EEP: A5-07-01
Data_byte3 = -
Data_byte2 = -
Data_byte1 = 0xC8 = halbautomatischeBewegungserkennung
0xFF = vollautomatische Bewegungserkennung
0x00 = keine Bewegung
Data_byte0 = 0x08
TF-Modus-Lerntelegramm: 0x1C080D
Schritt 1 wäre ja, FHEM mit dem o.g. Lerntelegramm an den Aktor anzulernen.
Ist so etwas möglich?
Danke und Gruß
Chris
Edit: Habe die commandref nochmal durch und bin jetzt über subtype=raw getolpert. Damit spiele ich jetzt erstmal rum
Edit 2: Funktioniert tatsächlich so einfach. Falls hier nochmal jemand so auf dem Schlauch stehen sollte, hier zum Re-Konstrurieren (für viele vermutlich offensichtlich):
- Neues device anlegen, z.B,. mit define NewDev EnOcean getNextId <EEP>
- attr <device> subtype raw
- Ziel-Aktor in Lernbereitschaft setzen, hier bei den Tipp-Funk-Aktoren einfach mit set <other_device> local learn
- Im neuangelegten Device nun das Lerntelegramm versenden, hier set <device> 4BS 1C080D0
- Nachdem der Ziel-Aktor quittiert hat, kann man nun analog bei Bedarf die anderen Telegramme versenden
Einen Bewegungsmelder Eltako TF61L kann man auch in Fhem über eine Erweiterung des vorhandenen Profils occupSensor.01 simulieren. Z. B. für die Wandkontroller Eltako FTR55D, FTR55H, Thermokon SR04 *, Thanos SR * gibt es solch einen virtuellen Kontroller; Profil roomSensorControl.05. Wenn der Komfort ausreicht, kommt man aber bei dem Profil occupSensor.01 auch mit der Eingabe des passenden Datenpakets über das raw-Profil - wie beschrieben - zum Ziel.
Falls das mit dem raw-Profil auf Dauer zu umständlich ist, bitte nochmals melden.
Zitat von: klaus.schauer am 26 Januar 2021, 07:08:46
. Z. B. für die Wandkontroller Eltako FTR55D, FTR55H, Thermokon SR04 *, Thanos SR * gibt es solch einen virtuellen Kontroller; Profil roomSensorControl.05. Wenn der Komfort ausreicht, kommt man aber bei dem Profil occupSensor.01 auch mit der Eingabe des passenden Datenpakets über das raw-Profil - wie beschrieben - zum Ziel.
Hallo Klaus,
danke für die Rückmeldung! Ich habe hier einige FTR55DSB/TF-TRDB55, bei denen ich mich immer gefragt habe, was die Set-Funktionen bewirken, da sie ja nicht direkt die Werte des FTR verändern können. Wenn ich dich jetzt richtig verstanden habe verhält sich das analog zu meinem Anwendungsfall mit dem Bewegungsmelder. Ich kann das Profil roomSensorControl.05 nutzen, um damit ein virtuelles Gerät anzulegen, welches dann wie ein echter FTR55 agieren kann. Wenn dem so ist, hätte ich hier dann vielleicht eine Anregung, da die grundsätzliche Idee sehr gut ist: Es wäre gut, wenn man für ein Device/Profil festlegen kann, ob es physisch oder virtuell genutzt wird. Bei virtueller Nutzung kommen dann die entsprechenden Befehle hinzu.
Zitat von: klaus.schauer am 26 Januar 2021, 07:08:46
Falls das mit dem raw-Profil auf Dauer zu umständlich ist, bitte nochmals melden.
Da ich das Raw-Format statisch per Notify versende, ist das aktuell für mich in Ordnung. Gehört für eher in die Kategorie nice to have. Das es aber für roomSensorControl.05 auch funktioniert wäre das natürlich konsistent.
Danke schon mal!
Zitat von: Flachzange am 26 Januar 2021, 15:59:59
Ich habe hier einige FTR55DSB/TF-TRDB55, bei denen ich mich immer gefragt habe, was die Set-Funktionen bewirken, da sie ja nicht direkt die Werte des FTR verändern können. Wenn ich dich jetzt richtig verstanden habe verhält sich das analog zu meinem Anwendungsfall mit dem Bewegungsmelder. Ich kann das Profil roomSensorControl.05 nutzen, um damit ein virtuelles Gerät anzulegen, welches dann wie ein echter FTR55 agieren kann.
Genau, dann benötigt man nur einen Temperatursensor im Raum als Referenzdevice.
Zitat
Es wäre gut, wenn man für ein Device/Profil festlegen kann, ob es physisch oder virtuell genutzt wird. Bei virtueller Nutzung kommen dann die entsprechenden Befehle hinzu.
Dass auch die set-Funktionen angezeigt werden, ist eher historisch bedingt. Im EnOcean-Modul war es immer schon so, dass z. B. beim Profil "switch" auch die set-Funktionen angezeigt werden, auch wenn man das Profil einfach nur zur Anzeige der Schaltertelegramme verwendet. Ich habe das beibehalten und nur bei komplexeren Profilen eine Master-/Slave-Unterscheidung eingebaut. Wäre aber sicherlich auch für andere Profile eine gute Option.
Zitat
Da ich das Raw-Format statisch per Notify versende, ist das aktuell für mich in Ordnung. Gehört für eher in die Kategorie nice to have. Das es aber für roomSensorControl.05 auch funktioniert wäre das natürlich konsistent.
Werde meine ToDo-Liste mal erweitern.
Bei den Profilen EEP A5-10-02, A5-10-03, A5-10-06 (roomSensorControl.05), EEP A5-10-10, A5-10-12 (roomSensorControl.01) können jetzt die set-Kommandos per Attribut devMode ausgeblendet werden. Die Funktionen stehen per Update zur Verfügung.
Das klingt gut. Ich wollte es gerade mal testen, aber es tut sich nichts. Ich nehme an, dass ich devMode=slave setzen muss, um die set-Kommandos auszublenden. In dem Fall ist es roomSensorControl.05:
Internals:
DEF 01A60BC3
FUUID 5c476ce8-f33f-fd7e-b7b1-d31c434ebd9add8d
IODev TCM_ESP3_0
LASTInputDev TCM_ESP3_0
MSGCNT 117
NAME Raumcontroller_Buero
NR 89
NTFY_ORDER 50-Raumcontroller_Buero
STATE T: 19.0 SPT: 19.5 NR: 0
TCM_ESP3_0_DestinationID FFFFFFFF
TCM_ESP3_0_MSGCNT 117
TCM_ESP3_0_PacketType 1
TCM_ESP3_0_RSSI -67
TCM_ESP3_0_ReceivingQuality excellent
TCM_ESP3_0_RepeatingCounter 1
TCM_ESP3_0_SubTelNum 8
TCM_ESP3_0_TIME 2021-02-09 06:37:00
TYPE EnOcean
Helper:
DBLOG:
nightReduction:
logdb:
TIME 1612849020.84641
VALUE 0
setpointTemp:
logdb:
TIME 1612849020.84641
VALUE 19.5
state:
logdb:
TIME 1612849020.84641
VALUE T: 19.0 SPT: 19.5 NR: 0
temperature:
logdb:
TIME 1612849020.84641
VALUE 19.0
READINGS:
2018-12-04 18:30:38 block unlock
2018-12-04 18:30:38 executeTime 0.0
2021-02-09 06:37:00 nightReduction 0
2021-02-09 06:37:00 setpointTemp 19.5
2021-02-09 06:37:00 state T: 19.0 SPT: 19.5 NR: 0
2018-12-04 18:32:07 teach 4BS teach-in accepted EEP A5-10-06 Manufacturer: Eltako
2021-02-09 06:37:00 temperature 19.0
helper:
Attributes:
IODev TCM_ESP3_0
devMode slave
eep A5-10-06
event-min-interval temperature:300
manufID 00D
phyLocation Über Bewegungsmelder an Säule
room Heizung
subType roomSensorControl.05
teachMethod 4BS
Edit: Irgendwie scheint das Update mir nicht gewirkt zu haben, da auch die Änderungen für signOfLife (anderes Device) nicht funktionieren
Update ist jetzt da und funktioniert.
Vielen Dank!
Zitat von: klaus.schauer am 26 Januar 2021, 17:36:08
Option.Werde meine ToDo-Liste mal erweitern.
Hallo Klaus,
ich wollte mal vorsichtig nachfragen, wo Du hier stehst.
Ich glaube mittlerweile einen Fehler in den Eltako Bewegungsmeldern ausgemacht zu haben (motion=on wird nicht sauber gesendet). In der Konsequenz schalten meine Lampen trotz Bewegung aus. Als Workaround würde ich gerne in diesen Fällen ein Bewegttelegramm vom Gateway senden. Dabei würde es mir sehr helfen, wenn die set commands verfügbar wären (idealerweise auch für den Telegrammtyp "halbautomatischer Modus"), weil ich dann nicht für jeden Bewegungsmelder einen weiteren händisch anlegen muss.
Danke und Gruß
Chris
Ich habe die Erweiterung bisher nicht weiterverfolgt. Irgendwie klang es so, dass es auch ohne gehen würde. Diverse andere Baustellen hatten und haben bei mit augenblicklich Priorität. Erweiterungen des EnOcean-Moduls habe ich deshalb nicht vorangetrieben.
Ich nehme mich der Sache nun aber in den nächsten Wochen an.
Ich habe mir jetzt die Funktion des Bewegungsmelders https://www.eltako.com/fileadmin/downloads/de/_bedienung/FBH55SB_30000514-1_dt.pdf (https://www.eltako.com/fileadmin/downloads/de/_bedienung/FBH55SB_30000514-1_dt.pdf) angesehen. Die Funktionen kann man durchaus im EnOcean-Modul virtuell abbilden. Ich frage mich nur, was man damit erreichen kann?
Als Vergleich kann man beim Profil roomSensorControl.05 einen Raumkontroller simulieren. Wenn man einen preiswerten Temperatursensor als Referenz verwendet, ist dieses Profil eine gute Alternative zum Gerät an der Wand.
Bei einem virtuellen Bewegungsmelder fallen mir auf Anhieb keine sinnvollen Einsatzgebiete ein. Einen im Raum montierten Bewegungsmelder benötige ich weiterhin. Den könnte ich auch gleich in den Aktor einlernen.
Was soll also mit einen virtuellen Bewegungsmelder zusätzlich erreicht werden?
Welche Reverenzgeräte sollen ausgewertet werden?
Welche Steuerfunktionen und Parameter sind notwendig?
Hallo Klaus,
zunächst einmal danke, dass Du Dir das Thema angeschaut hast. Es gibt hier drei Anwendungsfälle für mich, die alle darauf basieren, dass nur die besonderen TF-Telegrammtypen die Rückfallverzögerung im TF61L auslösen:
- Nur Bewegungsmelder vom Typ occupSensor.01 / A5-07-01 lassen sich in einen TF61L einlernen. Mit dem simulierten Telegramm könnte ich auch die weitverbreiteten lightTempOccupSensor.01 / A5-08-01 nutzen ohne, dass ich mir selber Logik bauen muss. Hier bietet sich beispielsweise ein reference device an
- Ein von FHEM gesendetes "set on" oder auch "set on-for-timer" übergeht die interne Rückfallverzögerung vom TF61L und schaltet Dauerlicht bzw dauerhaft aus. Würde ich statt "set on" ein Bewegt-Telegramm schicken, bleibe ich in der Logik, die auch jetzt schon in jedem Raum durch TF61L und FBH55SB herrscht. Konkretes Beispiel: Meine Bewegungsmelder in der Küche laufen im halbautomatischen Modus, schalten also nur wenn ich vorher manuell eingeschaltet habe. Wenn ich aber morgens aufstehe soll das Licht in der Küche automatisch einschalten. Dafür benutze ich derzeit ein simuliertes Telegramm, damit das Licht bei Bewegung in der Küche eingeschaltet bleibt und bei fehlender Bewegung ausgeschaltet wird.
- (Ich analysiere gerade einen potentiellen Fehler in den Bewegungsmeldern, der dazu führt, dass irgendwann das Bewegt-Telegramm ausbleibt, obwohl Bewegung im Raum ist. Diese Fälle kann ich dank FEHM mittlerweile systematisch erkennen und durch ein simuliertes Bewegttelegramm verhindern, dass der TF61L das Licht im Raum ausschaltet.)
Zu Deinen Fragen:
- In Summe braucht das Device drei set-Befehle (halbautomatisch, vollautomatisch, teach-in).
- Ein ReferenceDev ist für den Fall interessant, wenn man "motion" von einem anderen Melder übernehmen möchte
- Vermutlich müsste man das Device selbst als voll- oder halbautomatisch konfigurieren, damit im Falle von ReferenceDev klar ist, was gesendet werden soll
Sicherlich keine Funktionalität für die breite Masse, aber wenn es sich ohne große Stunts umsetzen ließe, wäre das super.
Danke und Gruß
Chris
Mit dem morgigen Update steht das neue Profil Presence Sensor (Master) [occupSensor.01 (EEP A5-07-01)] zur Verfügung. Einrichtung über ein inoffizielles EEP:
define <device> EnOcean H5-07-01
Alles weitere im commandref.
Vielen vielen Dank. Ich teste und melde mich dann.
Um die Eltako spezifischen Befehle fullyOn und semiOn zu sehen, ist
attr <device> manufID 00D
zu setzen.
Hi Klaus,
hatte ich gesehen, wäre es ggf. sinnvoll das gleich beim autocreate zu setzen?
Detailierte Rückmeldung:
- motionRefDev funktioniert gut
- devMode=master funktioniert insgesamt gut
- devMode=master wurde für alle vorhandenen devices mit Profil occupSensor.01 gesetzt. Vermutlich ist devMode=slave eher der Standardfall und master nur, wenn man über H5-A7-01 erstellt
- state=fullyOn/semiOn sollte immer nur "on" sein. Das ist insgesamt kompatibler. Die Info, ob es über fully/semi kam, kann man sich auch anderweitig holen, wenn man sie denn jetzt braucht
- Ich hadere etwas mit devUpdate. Hier wäre ich für "weniger ist mehr". Wenn man das braucht kann man es sich per notfiy und Co. nachbauen. Hat man hier einen realen Bewegungsmelder hinterlegt muss man es auf eh auf "off" stellen. Steht es auf "off", sendet das Device nach 120 Sekunden ein "off", wenn man vorher ein "on" getriggert hat. Diese Logik kollidiert, wenn das Device auch gleichzeitig ein physischer Melder ist, der ja im selben Zeitraum durchaus ein "on" senden kann. Aus meiner Sicht braucht man "devUpdate" nicht, falls Du hier aber Anwendungsfälle siehst, wäre es möglich ein "real off" einzuführen, bei dem überhaupt keine interne Logik greift?
- Das mit teachIn gesendete Lerntelegramm funktionierte bei mir nicht. Ich muss hier 1C080D80 senden (aus der Eltako-Doku).
An dieser Stelle nochmal Danke, dass Du diesen Sonderfall umgesetzt hat.
Die Wünsche werden mit dem morgigen Update erfüllt.
Fantastisch. Vielen Dank. Ich habe ein bisschen rumgespielt und es sieht alles gut aus.