Hallo,
ich würde mir mittels Notify gerne eine Mail senden lassen, sobald die Haustüre geöffnet oder wieder geschlossen wird. Leider sendet der FHTTK in regelmäßig unregelmäßigen Abständen den Status Closed und ich bekomme dann immer eine Mail. Leider gibt es beim CUL_FHTTK das Attribut event-on-change-reading nicht. Meine Frage aufgrund mangelnder Programmierkenntisse, wie kann man die Funktionalität nachbilden oder findet sich jemand, der CUL_FHTTK um das Attribut erweitert?
Viele Grüße
Klaus
Hallo,
also meine FHTTK haben das attr event-on-change-reading
Evtl. mal ein update machen ;-)
Grüße
Hallo Puschel74,
ich habe heute erst ein Update durchgeführt.
Meine Version ist:
# $Id: 09_CUL_FHTTK.pm 2076 2012-11-04 13:49:43Z rudolfkoenig $
Hast Du eine neuere?
Viele Grüße
Klaus
Hallo,
ZitatHast Du eine neuere?
Glaub ich kaum da mein update schon länger her ist.
Aber
(siehe Anhang / see attachement)
Grüße
Hallo,
kannst Du bitte mal deine Version-Nummer ausgeben? Ich habe einfach mal versucht das attribut händisch mit
attr Haustuer event-on-change-reading Window
zu setzen, bekomme aber folgende Fehlermeldung:
Haustuer: unknown attribute event-on-change-reading, choose one of verbose:0,1,2,3,4,5 room group comment alias eventMap userReadings IODev do_not_notify:1,0 ignore:0,1 showtime:0,1 model:FHT80TF loglevel:0,1,2,3,4,5,6 Fenster Fenster_map devStateIcon devStateStyle fm_fav fm_groups fm_name fm_order fm_type fm_view fp_0_Dashboard fp_0_Erdgeschoss fp_1_Obergeschoss fp_2_Dachgeschoss icon room_map sortby structexclude webCmd or use attr global userattr event-on-change-reading
Gruß
Klaus
Hallo,
die Fehlermeldung hab ich fast vermutet ;-)
Setz mal ein attr global userattr event-on-change-reading
(siehe Anhang / see attachement)
Dann verschwindet die Fehlermeldung und du kannst das Attribut bei den FHTTK auch auswählen.
Grüße
Zitatattr global userattr event-on-change-reading
:) Herrlich.
Natuerlich gibt es danach keine Fehlermeldung mehr, aber auch keine zusaetzliche Funktionalitaet.
Die in http://fhem.de/commandref.html#readingFnAttributes (//fhem.de/commandref.html#readingFnAttributes) beschriebenen Attribute funktionieren nur dann, falls der Autor sein Modul auf die "neuen" readingsUpdate Funktionen umgestellt hat, in diesem Fall sollten auch die Attribute angezeigt werden.
Der CUL_FHTTK Maintainer hat sich hier im Forum seit Anfang Januar nicht gemeldet (wenn ich es richtig sehe), damit ist das Modul verwaist, und falls sich keiner meldet, dann erbe ich es (ich sollte mich in init umbenennen :). Nach 5.5 werde ich es mir anschauen, lieber waere mir aber jemand anderes als Maintainer, da ich es nicht testen kann.
Hallo,
dann würde ich dem Klaus bis auf Weiteres diese Lösung (//www.fhemwiki.de/wiki/FHTTK:_Benachrichtigung_bei_offenem_Fenster) empfehlen, die auch bei mir seit Langem gut und zuverlässig funktioniert.
Gruß
Frank
Zitat von: rudolfkoenig schrieb am Sa, 07 September 2013 08:45Zitatattr global userattr event-on-change-reading
:) Herrlich.
Natuerlich gibt es danach keine Fehlermeldung mehr, aber auch keine zusaetzliche Funktionalitaet.
Die in http://fhem.de/commandref.html#readingFnAttributes beschriebenen Attribute funktionieren nur dann, falls der Autor sein Modul auf die "neuen" readingsUpdate Funktionen umgestellt hat, in diesem Fall sollten auch die Attribute angezeigt werden.
Der CUL_FHTTK Maintainer hat sich hier im Forum seit Anfang Januar nicht gemeldet (wenn ich es richtig sehe), damit ist das Modul verwaist, und falls sich keiner meldet, dann erbe ich es (ich sollte mich in init umbenennen :). Nach 5.5 werde ich es mir anschauen, lieber waere mir aber jemand anderes als Maintainer, da ich es nicht testen kann.
Hallo Rudolf,
vielen Dank für dein Angebot das Modul entsprechend zu erweitern. Bezgl. des Testens könnte ich dich gerne unterstützen.
Viele Grüße
Klaus
PS: Aufgrund Urlaub ist die Antwort leider etwas verspätet
MoinMoin,
Frage:
ist nämliches inzwischen eingebaut ?
Ich wünsche mir das auch,
kann aber bei CUL_FHTTKs kein event-on-irgendwas auswählen.
*grübel*
Hallo,
ich bin auch darüber gestolpert. Habe 10 x FH80B mit FHTK im Einsatz.
Mein Workaround: 10 dummys definieren und per notify einen Statuswechsel der Fenster dort merken, einschl. der Zeit.
Das stateFormat der dummys habe ich dann um: "state seit" (Statuszeit ist ein userreading) erweitert, so dass man dann die Ausgabe:
Fenster (Büro) geschlossen seit 10:11:06 27.11.2013
erhält.
Da manche FHTKs nur schlecht vom CUL wegen Distanz und baulichen Gegebenheiten "gesehen" werden, habe ich in das notify auch das windows - Reading der Thermostate mit eingebunden.
Gruß
Elektrolurch
Statuszeit
Hallo Zusammen,
ich habe mich mal an das Modul gewagt und es mal eingebaut. Soweit ich das hier remote testen kann, funktioniert es soweit.
Vllt. kann einer von Euch es auch noch testen und wenn es tut kann es von jemanden der dazu rechte hat, eingecheckt werden. :)
Viele Grüße.
Hallo,
klasse, dass du dich des Themas angenommen hast. Ich habs mal reingehängt. Bisher scheint alles ok zu sein.
Gebe dann noch mal Feedback.
Christof
Hallo,
habe mir heute Abend etwas Zeit genommen und getestet bzw. ergänzt.
Mir ist aufgefallen, dass mit dem alten Modul nur
2013-12-10_23:06:34 gt_fenster Window: Closed
gelogged wurde. Jetzt kommt immer:
2013-12-10_23:10:38 gt_fenster Window: Closed
2013-12-10_23:10:38 gt_fenster Reliability: ok
2013-12-10_23:10:38 gt_fenster Battery: ok
2013-12-10_23:10:38 gt_fenster Window: Closed
Zu deiner Unterstützung habe ich mir die leichte Übung genommen und auf Log3 umgestellt und Autocreate wieder mit eingefügt und getestet. Funktioniert inkl. logging des neu angelegten Devices prima.
2013.12.10 23:22:50 1: FHTTK Unknown device d6b396, please define it
2013.12.10 23:22:50 2: autocreate: define CUL_FHTTK_d6b396 CUL_FHTTK d6b396
2013.12.10 23:22:50 2: autocreate: define FileLog_CUL_FHTTK_d6b396 FileLog ./log/CUL_FHTTK_d6b396-%Y-%m.log CUL_FHTTK_d6b396
2013.12.10 23:22:50 2: autocreate: define SVG_CUL_FHTTK_d6b396 SVG FileLog_CUL_FHTTK_d6b396:fht80tf:CURRENT
Vllt. mag noch jemand mittesten.
Hallo,
ah sehr gut danke. Dann werde ich Dein angepasstes auch gleich übernehmen und mittesten. :)
Hallo,
ich werde heute auch mal testen und geb dann morgen Status.
Viele Grüße und Danke für die Arbeit.
Klaus
Hallo,
ich habe noch Zeile 251 auskommentiert, da wir das Readings sonst doppelt haben.
Bisher keine Probleme.
Christof
Hallo,
stimmt ist mir gar nicht aufgefallen, da ich schon event-on-change auf Window gesetzt hatte. :)
Danke Christof. :) Auch bei mir weiterhin ohne Probleme.
Grüße,
Steve
Oh, hat sich ja was getan.
Danke schön für die geleistete Arbeit *top*
Kann im Moment leider nicht mittesten, da ich andernorts bin.
Hallo,
der Test läuft hervorragend, alles perfekt.
Danke
Kann mich nur anschließen, Test lief bisher erfolgreich
Danke
Salvadore
Okay das freut. :)
Ich habe nur noch eine kosmetsiche Änderung vorgenommen und die Hilfe ergänzt.
@Rudi:
Wenns für Dich okay ist, könntest Du es dann einchecken?
Danke und Grüße,
Steve
Moin,
habe die letzte - von über mir - nun auch ausprobiert und bin begeistert, Danke, so wollte ich die LOGs schon immer.
Ein kleiner Schönheitsfehler:
Wenn vorher die Glühbirne bei attr FHTTKName eventMap Closed:off Open:on leuchtete oder auch nicht, dann ist es nun so, dass dies wohl irgendwie "überschrieben" wird und nun nur noch ein schnödes Open oder Closed erscheint.
Ich möchte aber die Glühbirne wiederhaben.
Nachtisch:
Mit attr FHTTKName devStateIcon Closed:off Open:on glühbirnt es wieder :-)
Hallo,
wurde die Änderungen auch ins fhem eingestellt? Im letzten Stand gab es noch kein Attribut "event-on-change-reading".
Bei der aatrlist müsste .$RREADINGFNAttributes (? kann gerade nicht nachsehen , wie es richtig heißt) und in der parse - Routine das ganze Abfragezeugs auf change usw. meiner Meinung nach einfach durch readings'BuldUpdate ersetzt werden.
Oder sehe ich das falsch?
Elektrolurch
Hallo,
nein, da der Maintainer sich noch nicht gemeldet hat.
Gruß,
Steve
Hallo, ich habe ein Problem mit einem Fenstermelder FHTTK. Um den Log zu reduzieren habe ich event-on-change-reading und event-on-update-reading eingefügt. Der LOG wird auch wie gewünscht reduziert. Ich habe jedoch ein Problem mit dem State. Der State wird ja von Open:offen Closed:geschlossen gemappt. Aufgefallen ist mir das Problem, weil das devStateIcon nicht immer richtig angezeigt wird. Es scheint das bei jedem zweiten Event der State nicht gemappt wird, sondern bei Open bzw. Closed bleibt und so das falsche Icon interpretiert wird. Das ganze ist im übrigen in einer Stucture, aber bei den übrigen Meldern der Stuctur, bei den ich event-on-change-reading und event-on-update-reading noch nicht eingebaut habe, funktioniert es ja.
Gruß
cerberus
fhem.cfg
define Fenster_EG_Dusche CUL_FHTTK f6af5c
attr Fenster_EG_Dusche alias Fenster Dusche
attr Fenster_EG_Dusche eventMap Open:offen Closed:geschlossen
attr Fenster_EG_Dusche event-on-change-reading Battery,Reliability,Window
#attr Fenster_EG_Dusche event-on-update-reading Battery,Reliability,Window
attr Fenster_EG_Dusche event-min-interval Battery:3600,Reliability:3600,Window:600
attr Fenster_EG_Dusche icon fts_window_2w
attr Fenster_EG_Dusche devStateIcon offen:fts_window_1w_open@red geschlossen:fts_window_1w@green
attr Fenster_EG_Dusche fp_4_Erdgeschoss 550,896,0,
attr Fenster_EG_Dusche group Fenster_EG
attr Fenster_EG_Dusche room 12_Dusche,02_Fenster
LOG:
2014-02-10_10:22:39 Fenster_EG_Dusche Window: geschlossen
2014-02-10_10:35:03 Fenster_EG_Dusche Window: geschlossen
2014-02-10_10:47:27 Fenster_EG_Dusche Window: geschlossen
2014-02-10_10:59:51 Fenster_EG_Dusche Window: geschlossen
2014-02-10_11:05:01 Fenster_EG_Dusche Window: offen
2014-02-10_11:18:27 Fenster_EG_Dusche Window: offen
2014-02-10_11:22:35 Fenster_EG_Dusche Reliability: ok
2014-02-10_11:22:35 Fenster_EG_Dusche Battery: ok
2014-02-10_11:30:51 Fenster_EG_Dusche Window: offen
2014-02-10_11:43:15 Fenster_EG_Dusche Window: offen
2014-02-10_11:55:39 Fenster_EG_Dusche Window: offen
2014-02-10_12:12:11 Fenster_EG_Dusche Window: offen
2014-02-10_12:24:35 Fenster_EG_Dusche Window: offen
2014-02-10_12:24:35 Fenster_EG_Dusche Reliability: ok
2014-02-10_12:24:35 Fenster_EG_Dusche Battery: ok
2014-02-10_12:30:47 Fenster_EG_Dusche Window: geschlossen
2014-02-10_12:44:14 Fenster_EG_Dusche Window: geschlossen
Hallo cerberus,
Dein geschildertes Problem hatte ich bei mir noch nicht beobachten können. Vllt auch weil ich nicht explizit danach geschaut hatte. :)
Okay aber aus dem Bauch heraus würde ich auf Zeile : "attr Fenster_EG_Dusche event-min-interval Battery:3600,Reliability:3600,Window:600" tippen. Innerhalb der angegebenen Zeit werden keine events ausgelöst seit.
Gruß,
Steve
Hallo Matscher, das ist richtig, es sei den der Staus der Readings würde sich ändern. Das erklärt jedoch nicht warum der Status manchmal Offen und manchmal open bzw. Close und geschlossen ist. Warum wird das eventmap nicht berücksichtigt?
Gruß
cerberus
Hallo cerberus,
gute Frage ... teste mal bitte die neu angehängte Version. Ich hoffe das es Dein Problem beheben wird. :)
Gruß,
Matscher
Danke Matscher, werde es probieren. Ich bin aber ab Samstag 1 Woche im Skiurlaub, danach kann ich sicher schon was zum Ergebnis sagen.
Bis dahin
cerberus
Hallo Matscher, habe nochmal kurz Gelegenheit in meinen Homeserver zu schauen, bisher tritt das Problem nicht mehr auf. Wenn es so bleibt hast du das Problem gefixt.
Wann wird eigentlich die PM mal eingecheckt? Beim letzten Update Force wurde sie wieder durch die alte ohne Unterstützung von event-on-change-reading überschrieben.
Gruß
cerberus
Hallo cerberus,
das ist doch schonmal sehr gut. :)
Ich kümmere mich um einen Zugang, aber vorerst kannst Du "exclude_from_update" benutzen. Damit wird es beim Update ignoriert.
Gruß,
Steve
Hallo,
mit dem heutigen Update wird die PM mit den Änderungen verteilt.
Viele Grüße,
Matscher
Hallo Matscher, kann das sein das die Änderung mit den letzten Update wieder raus ist? Wenn ich in meine LOGS schaue, so scheint seit dem 01.04.2014
event-on-change-reading Battery,Reliability,Window
event-min-interval Battery:3600,Reliability:3600,Window:600
nicht mehr zu funktionieren und meine LOGS laufen wieder voll.
Dane und Gruß
cerberus
Hallo ceberus,
es hat seit dem 12.03.2014 keine Änderungen am Modul gegeben. Es sollte eigentlich noch funktionieren :)
Machst Du täglich ein Update? Dann würde ich mich auf die Suche machen, was genau vor dem 01.04. geändert wurde.
Gruß,
Matscher
Nein, nicht täglich. Aber ich habe das System neu aufgesetzt und daher vor kurzem das Update gemacht.
Ich schau nochmal alles durch.
Grüße
cerberus
So Matscher, habe nochmal die LOGs durchgeschaut, es ist doch alles okay. Hatte heute früh wohl die Augen noch nicht richtig offen.
Entschuldige die Umstände.
Danke und Gruß
cerberus
Hallo ceberus,
kein Problem, das kommt vor :)
Gruß,
Matscher