Hallo zusammen,
irgendwie habe ich ein Problem mit dem Notify.
Die Testdefinition sieht so aus:
define n_c50_Wandtaster notify c50_Wandtaster:(.*) { \
Log 1, "Test $value{c50_Wandtaster}" ;; \
]
Im Log des HM-PB-6-WM55 steht richtig:
2014-04-13_20:15:39 c50_Wandtaster battery: ok
2014-04-13_20:15:39 c50_Wandtaster c50_Wandtaster_Btn_02 Short (to HMLAN1)
2014-04-13_20:15:39 c50_Wandtaster CMDs_done
Im Log, das über das Notify erzeugt wird, steht jedes mal CMDs_done:
2014.04.13 20:15:39 1: Test CMDs_done
2014.04.13 20:15:39 1: Test CMDs_done
2014.04.13 20:15:39 1: Test CMDs_done
Somit werden die Notifys nicht richtig ausgeführt.
Bei den Testerschnittstellen HM-PBI-4-FM habe ich auch das Problem.
Kann mir da jemand helfen?
ist doch logisch... Du liest den STATE des Wandtasters (also des DEVICE) aus, und da steht nunmal "CMDs_done" drin - also völlig korrekt.
Was Du tun möchtest, ist den Zustand eines CHANNELS zu ermitteln, dann solltest Du auch den entsprechenden Channel angeben.
Übrigens: man verwendet nicht (mehr) $value{} sondern Value().
In Deinem Fall also
Value('c50_Wandtaster c50_Wandtaster_Btn_02 Short')
Noch besser wäre es allerdings, entweder mit ReadingsVal() zu arbeiten oder direkt das notify so (richtig) zu erstellen, dass es direkt auf den gewünschten Button reagiert und nicht auf das Device selbst.
Hallo betateilchen,
danke für den Tipp. Ich habe nun für jeden ein eigenes Notify erstellt.
Bei der Fernbedienung HM-RC-4-B scheint das aber nicht zu funktionieren, da für beide Tastenpaare immer offShort und onShort ausgegeben wird. Somit habe ich keine Möglichkeit beide Paare zu nutzen.
Hast Du da noch eine Idee, oder muss Martin da noch etwas nachbessern?
sorry, diese Fernbedienung ist mir noch nicht untergekommen. Aber irgendwie müssen sich doch die beiden Tastenpaare unterscheiden lassen?
Schau doch mal in den Eventmonitor und drücke die vier Tasten nacheinander.
Die Ausgabe dann bitte hier posten - ich kann mir nicht vorstellen, dass es da keine Unterschiede gibt.
Das ist eine kleine, die man an den Schlüssel machen kann.
Das mit dem Eventmonitor habe ich schon gemacht. Wie gesagt da kommt auf beiden Paaren das selbe Ereignis.
Log:
2014-04-13_23:06:01 Auto_Remote_1 offShort (to broadcast) <-- Taster links oben
2014-04-13_23:06:01 Auto_Remote_1 trigger: Short_111
2014-04-13_23:06:01 Auto_Remote_1 battery: low
2014-04-13_23:06:06 Auto_Remote_1 offShort (to broadcast) <-- Taster links unten
2014-04-13_23:06:06 Auto_Remote_1 trigger: Short_87
2014-04-13_23:06:06 Auto_Remote_1 battery: low
2014-04-13_23:06:12 Auto_Remote_1 onShort (to broadcast) <-- Taster rechts oben
2014-04-13_23:06:12 Auto_Remote_1 trigger: Short_5
2014-04-13_23:06:12 Auto_Remote_1 battery: low
2014-04-13_23:06:13 Auto_Remote_1 onShort (to broadcast) <-- Taster rechts unten
2014-04-13_23:06:13 Auto_Remote_1 trigger: Short_42
2014-04-13_23:06:13 Auto_Remote_1 battery: low
lustig...
kannst Du mal bitte ein "list <device>" machen? <device> ist dabei der Name der Fernbedienung.
Jepp:
Internals:
CFGFN /usr/share/fhem/FHEM_CONF/0004_definition_hm.pm
DEF 18E47D
IODev HMLAN1
NAME Auto_Remote_1
NR 176
STATE offShort (to broadcast)
TYPE CUL_HM
Readings:
2014-04-13 01:22:42 D-firmware 1.3
2014-04-13 01:22:42 D-serialNr IEQ0521610
2014-04-14 06:55:45 battery low
2014-04-14 06:55:45 state offShort (to broadcast)
2014-04-14 06:55:45 trigger Short_113
Helper:
mId 003B
rxType 4
Io:
newChn +18E47D,00,01,FE1F
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Attributes:
IODev HMLAN1
autoReadReg 0
expert 2_full
firmware 1.3
model HM-RC-4-B
peerIDs
room CUL_HM
serialNr IEQ0521610
subType remote
Deine Fernbedienung ist nicht mit fhem gepaired - zumindest sendet sie an broadcast ?
Ich vermute dass deshalb die Channels fehlen und die Tasten nicht unterschieden werden können.
Versuch doch mal, die Fernbedienung zu pairen und mach den Test dann nochmal.
Das kann ich erst, wenn ich zu hause bin.
Gepairt hatte ich sie damals aber. Das sieht man ja auch am IODev HMLAN1. Aber ich werde sie nachher resetten und noch einmal Pairen.
Zitat von: Jörg am 14 April 2014, 15:32:25
Das sieht man ja auch am IODev HMLAN1.
Das IODev hat mit dem pairen überhaupt nichts zu tun.
Frohe Ostern. :)
Hat was länger gedauert, da ich hier noch renoviere.
Es läuft nun. Das Problem war, dass die Fernbedienung vor ca. 3 Jahren gepaired wurde. Da gab es das in FHEM noch nicht, dass jede Taste einzelnen aufgeführt wurde, sondern nur die Fernbedienung als ein Gerät.
Allerdings sendet sie weiterhin nur an (to broadcast). Das scheint mir aber ein Problem in der Firmware der Fernbedienung zu sein.
das eigentliche pairen war das gleiche. Das anlegen der Buttons oder eben nicht ist eine andere sache.
Du kannst dich entscheiden, jeden Button als Entity anzulegen geht automatisch, wenn du einfach einmal anlernen drückst) oder nur über das Device arbeitest (wird in FHEM kaum noch genutzt)
Das die FB ihre trigger nach broadcast sendet ist schon möglich -machen manche.
Der Button sollte aber immer erkennbar sein.
Zeichne doch einmal die trigger auf - rohmessages und die Events - wenn du unterschiedliche Buttons drückst.
Lese bei der Gelegenheit doch gleich die Register einmal aus.
Gruss Martin
Zitat von: martinp876 am 22 April 2014, 08:00:30
das eigentliche pairen war das gleiche. Das anlegen der Buttons oder eben nicht ist eine andere sache.
Du kannst dich entscheiden, jeden Button als Entity anzulegen geht automatisch, wenn du einfach einmal anlernen drückst) oder nur über das Device arbeitest (wird in FHEM kaum noch genutzt)
Meine Vorgehensweise ist, dass ich grundsätzlich alle Gräte direkt mit der Zentrale, also FHEM Paire. Dadurch habe ich den Vorteil, dass ich komplexe Makros ausführen kann.
ZitatDer Button sollte aber immer erkennbar sein.
Ja, ist es jetzt auch, nachdem ich den einzelnen Tasten ein Define verpasst habe.
ZitatZeichne doch einmal die trigger auf - rohmessages und die Events - wenn du unterschiedliche Buttons drückst.
Lese bei der Gelegenheit doch gleich die Register einmal aus.
Brauchst Du das noch, da es ja bei mir nun läuft. Wenn ja, das ist kein Problem, das zu erstellen.
LG Jörg
nein, brauche nichts,werde es selbst einmal testen.
Gruss Martin
Unabhängig davon habe ich gestern noch eine neue Fernbedienung (HM-RC-4-2) bekommen. Siehe da, die sendet nicht an Broadcast, sondern direkt an die HMLAN-Zentrale.
Also liegt es doch an der Firmware der Fernbedienung.
Was mir noch aufgefallen ist, dass das Autocreate nicht richtig funktioniert.
Normalerweise werden die Geräte in der fhem.cfg abgespeichert, aber der Vorgang bricht schon bei dem Eintrag für die Seriennummer ab.
Soll ich dafür einen extra Beitrag eröffnen, oder reicht das hier an dieser Stelle?
wird in FHEM alles angelegt nur das speichern funktioniert nicht?
Ich nehme als Beispiel die Fernbedienung HM-RC-4-2, die ich als letztes gepairt habe. Ein Außensensor, den ich vor einigen Tagen gepairt hatte, brachte das selbe Ergebnis.
Das, was fehlte habe ich von Hand eingetragen, dann funktionierten die Devices.
In der fhem.cfg wird nur das eingetragen:
define CUL_HM_HM_RC_4_2_252BAA CUL_HM 252BAA
attr CUL_HM_HM_RC_4_2_252BAA room CUL_HM
define FileLog_CUL_HM_HM_RC_4_2_252BAA FileLog /var/log/fhem/CUL_HM_HM_RC_4_2_252BAA-%Y.log CUL_HM_HM_RC_4_2_252BAA
attr FileLog_CUL_HM_HM_RC_4_2_252BAA logtype text
attr FileLog_CUL_HM_HM_RC_4_2_252BAA room CUL_HM
Im Log steht:
2014.04.24 02:16:36 2: CUL_HM Unknown device CUL_HM_HM_RC_4_2_252BAA is now defined
2014.04.24 02:16:36 2: autocreate: define CUL_HM_HM_RC_4_2_252BAA CUL_HM 252BAA
2014.04.24 02:16:36 2: autocreate: define FileLog_CUL_HM_HM_RC_4_2_252BAA FileLog /var/log/fhem/CUL_HM_HM_RC_4_2_252BAA-%Y.log CUL_HM_HM_RC_4_2_252BAA
2014.04.24 02:16:36 3: CUL_HM pair: CUL_HM_HM_RC_4_2_252BAA remote, model HM-RC-4-2 serialNr
2014.04.24 02:16:36 3: CUL_HM set CUL_HM_HM_RC_4_2_252BAA getConfig
2014.04.24 02:17:00 3: CUL_HM set CUL_HM_HM_RC_4_2_252BAA_Btn_04 getConfig
2014.04.24 02:17:01 3: CUL_HM pair: CUL_HM_HM_RC_4_2_252BAA remote, model HM-RC-4-2 serialNr KEQ1056101
2014.04.24 02:17:01 3: CUL_HM set CUL_HM_HM_RC_4_2_252BAA getConfig
2014.04.24 02:17:18 3: CUL_HM pair: CUL_HM_HM_RC_4_2_252BAA remote, model HM-RC-4-2 serialNr KEQ1056101
2014.04.24 02:17:18 3: CUL_HM set CUL_HM_HM_RC_4_2_252BAA getConfig
2014.04.24 02:17:35 3: CUL_HM pair: CUL_HM_HM_RC_4_2_252BAA remote, model HM-RC-4-2 serialNr KEQ1056101
2014.04.24 02:17:35 3: CUL_HM set CUL_HM_HM_RC_4_2_252BAA getConfig
2014.04.24 02:17:51 3: CUL_HM pair: CUL_HM_HM_RC_4_2_252BAA remote, model HM-RC-4-2 serialNr KEQ1056101
2014.04.24 02:17:51 3: CUL_HM set CUL_HM_HM_RC_4_2_252BAA getConfig
habe es gerade mit einer RC4 getestet. Geht doch eigentlich gut
2014-04-24 14:24:23.632 Global global UNDEFINED CUL_HM_HM_RC_4_2_212291 CUL_HM 212291
2014-04-24 14:24:23.632 Global global DEFINED CUL_HM_HM_RC_4_2_212291
2014-04-24 14:24:23.632 Global global SAVE
2014-04-24 14:24:23.667 Global global DEFINED CUL_HM_HM_RC_4_2_212291_Btn_01
2014-04-24 14:24:23.694 Global global DEFINED CUL_HM_HM_RC_4_2_212291_Btn_02
2014-04-24 14:24:23.719 Global global DEFINED CUL_HM_HM_RC_4_2_212291_Btn_03
2014-04-24 14:24:23.746 Global global DEFINED CUL_HM_HM_RC_4_2_212291_Btn_04
2014-04-24 14:24:23.787 CUL_HM CUL_HM_HM_RC_4_2_212291 D-firmware: 1.0
2014-04-24 14:24:23.787 CUL_HM CUL_HM_HM_RC_4_2_212291 D-serialNr: KEQ0111556
2014-04-24 14:24:23.787 CUL_HM CUL_HM_HM_RC_4_2_212291 CMDs_done
2014-04-24 14:24:23.899 CUL_HM CUL_HM_HM_RC_4_2_212291 D-firmware: 1.0
2014-04-24 14:24:23.899 CUL_HM CUL_HM_HM_RC_4_2_212291 D-serialNr: KEQ0111556
2014-04-24 14:24:23.899 CUL_HM CUL_HM_HM_RC_4_2_212291 R-pairCentral: set_0x1743BF
2014-04-24 14:24:23.899 CUL_HM CUL_HM_HM_RC_4_2_212291 CMDs_pending
2014-04-24 14:24:23.899 CUL_HM CUL_HM_HM_RC_4_2_212291 CMDs_pending
2014-04-24 14:24:23.899 CUL_HM CUL_HM_HM_RC_4_2_212291 CMDs_pending
2014-04-24 14:24:23.899 CUL_HM CUL_HM_HM_RC_4_2_212291 CMDs_pending
2014-04-24 14:24:23.899 CUL_HM CUL_HM_HM_RC_4_2_212291 CMDs_pending
2014-04-24 14:24:23.899 CUL_HM CUL_HM_HM_RC_4_2_212291 CMDs_pending
2014-04-24 14:24:23.899 CUL_HM CUL_HM_HM_RC_4_2_212291 CMDs_pending
2014-04-24 14:24:23.899 CUL_HM CUL_HM_HM_RC_4_2_212291 CMDs_pending
2014-04-24 14:24:23.899 CUL_HM CUL_HM_HM_RC_4_2_212291 CMDs_pending
2014-04-24 14:24:23.899 CUL_HM CUL_HM_HM_RC_4_2_212291 CMDs_pending
2014-04-24 14:24:23.899 CUL_HM CUL_HM_HM_RC_4_2_212291 CMDs_pending
2014-04-24 14:24:23.899 CUL_HM CUL_HM_HM_RC_4_2_212291 CMDs_pending
2014-04-24 14:24:24.068 CUL_HM CUL_HM_HM_RC_4_2_212291 D-firmware: 1.0
2014-04-24 14:24:24.068 CUL_HM CUL_HM_HM_RC_4_2_212291 D-serialNr: KEQ0111556
2014-04-24 14:24:24.241 CUL_HM CUL_HM_HM_RC_4_2_212291 D-firmware: 1.0
2014-04-24 14:24:24.241 CUL_HM CUL_HM_HM_RC_4_2_212291 D-serialNr: KEQ0111556
2014-04-24 14:24:24.286 CUL_HM CUL_HM_HM_RC_4_2_212291 D-firmware: 1.0
2014-04-24 14:24:24.286 CUL_HM CUL_HM_HM_RC_4_2_212291 D-serialNr: KEQ0111556
2014-04-24 14:24:24.329 CUL_HM CUL_HM_HM_RC_4_2_212291 D-firmware: 1.0
2014-04-24 14:24:24.329 CUL_HM CUL_HM_HM_RC_4_2_212291 D-serialNr: KEQ0111556
2014-04-24 14:24:26.008 CUL_HM CUL_HM_HM_RC_4_2_212291 R-pairCentral: 0x1743BF
2014-04-24 14:24:26.526 CUL_HM CUL_HM_HM_RC_4_2_212291_Btn_01 R-sign: off
2014-04-24 14:24:27.556 CUL_HM CUL_HM_HM_RC_4_2_212291_Btn_02 R-sign: off
2014-04-24 14:24:28.594 CUL_HM CUL_HM_HM_RC_4_2_212291_Btn_03 R-sign: off
2014-04-24 14:24:29.633 CUL_HM CUL_HM_HM_RC_4_2_212291_Btn_04 R-longPress: 0.4 s
2014-04-24 14:24:29.633 CUL_HM CUL_HM_HM_RC_4_2_212291_Btn_04 R-dblPress: 0 s
2014-04-24 14:24:29.633 CUL_HM CUL_HM_HM_RC_4_2_212291_Btn_04 R-sign: off
2014-04-24 14:24:30.664 CUL_HM CUL_HM_HM_RC_4_2_212291 CMDs_done
2014-04-24 14:24:30.681 CUL_HM CUL_HM_HM_RC_4_2_212291_Btn_01 R-swBa_chn-01-expectAES: off
2014-04-24 14:24:30.681 CUL_HM CUL_HM_HM_RC_4_2_212291_Btn_01 R-swBa_chn-01-peerNeedsBurst: on
was ich nicht nutze ist dieses auto-anlegen von Logfiles...
Ausserdem wird nur das Device automatisch in fhem.cfg gespeichert, ich müsste ein Save anschliessen.
Du könntest alternativ nach dem pairen noch einmal - ohne hmPairForSec - anlernen drücken - FHEM würde alle deine fehlenden Devices anlegen.
- das mit dem autocreate von logs werde ich einmal testen (obwohl das Anlege so vieler logfiles eigentlich keinen Sinn macht)
- das automatische save ist m.E. nicht hinreichend, da es auch andere Änderungen wir attribute nicht abfängt.
- In CUL_HM habe ich schwierigkeiten, das alles hin zu bekommen. Zum einen muss ich relativ schnell sein um auch pairen zu können (das Device legt sich gleich wieder schlafen...) zum anderen haben die anderen Funktionen viel Zeit, files und ähnliches anzulegen - das dauert einfach zu lang. Leider habe ich kein sauberes Interface dies nach getaner Arbeit zu triggern....
Gruss Martin
Hmm - Hat sich denn im Laufe der letzten Zeit etwas an der Definition für das Autocreate geändert?
meine sieht so aus:
define autocreate autocreate
attr autocreate autosave 1
attr autocreate device_room %TYPE
attr autocreate filelog /var/log/fhem/%NAME-%Y.log
attr autocreate weblink 1
attr autocreate weblink_room Plots
an der definition nicht... höchstens an der Ausführung.
Ich nutze kein autosave. Grund: das speichert wann es will - nicht immer und nicht, wenn ich es will. daher ist es zu ungenau und fliegt bei mir raus.
Autosave könnte etwas mit dem Problem zu tun haben, da beim pairen n Entities angelegt werden müssen - und zwar zwischen rein.... das kostet Zeit und macht das Timing hin.
Ausserdem kein autocreate filelog: Ein logfile je entity (button) halte ich für sinnlos. So werte ich dies NIE aus. Ich habe ein sammel-log in dem alle Aktionen geloggt werden. Hier kann ich dann zusammenhänge erkennen, oder nach einzelnen Aktoren filtern - falls ich einmal suchen gehe. FHEM hat somit weniger Notifies, weniger Performance und weniger files zu handeln.
Auch dies will während der pairing -aktion angelegt werden... gleiches Problem wie oben.
Ich gehe davon aus, dass dies die beiden Problemstellen sind - den wir sollten auf das gleiche Ergebnis kommen.
Evtl versuche ich die Stellen zu bereinigen - aber die Schnittstellen hierzu sind etwas verbaut in FHEM....
Gruss Martin