Hallo Zusammen,
ich wollte einen HomeMatic Taster (HM-PB-2-WM55 2fach-Funk-Wandtaster) ein Licht einer Steckdose (auch von HM) anschalten.
Beide HM Komponenten an sich laufen gut und sind in FHEM auch korrekt drin denk ich.
Zuerst hatte ich über smartPeer in FHEM den Schalter direkt mit der Steckdose verbunden, dann gings auch.
Dass Problem ist, dass ich gerne dass Licht dann nur für 30 Minuten an hätte. Hierzu hatte ich ein Notify (define TasterObenLang notify HM_6AA782_Btn_02:Long.* set Steckdose_Sw on-for-timer 900) eingerichtet. Die Zeitangabe hat aber leider nicht gegriffen. Das Licht blieb permanent an.
Nun habe ich über smartPeer das direkte Peering wieder rausgenommen und dachte ich kann über den Notify alleine die Steckdose auch anschalten und dann die Zeitangabe mitgeben.
Leider reagiert der Taster nun nicht mehr, die Steckdose bleibt aus.
In den Logs sehe ich dass der Taster die Befehle (kurzes Drücken und langes Drücken) jeweils erkennt.
2019-06-15_09:38:14 TasterSteckdose battery: ok
2019-06-15_09:38:14 TasterSteckdose TasterSteckdose_Btn_02 Short
2019-06-15_09:38:17 TasterSteckdose battery: ok
2019-06-15_09:38:17 TasterSteckdose TasterSteckdose_Btn_01 Short
2019-06-15_09:38:20 TasterSteckdose battery: ok
2019-06-15_09:38:20 TasterSteckdose TasterSteckdose_Btn_02 Long
2019-06-15_09:38:21 TasterSteckdose battery: ok
2019-06-15_09:38:21 TasterSteckdose TasterSteckdose_Btn_02 Long
2019-06-15_09:38:21 TasterSteckdose battery: ok
2019-06-15_09:38:21 TasterSteckdose TasterSteckdose_Btn_02 Long
2019-06-15_09:38:21 TasterSteckdose battery: ok
2019-06-15_09:38:21 TasterSteckdose TasterSteckdose_Btn_02 LongRelease
2019-06-15_09:38:24 TasterSteckdose battery: ok
2019-06-15_09:38:24 TasterSteckdose TasterSteckdose_Btn_01 Long
2019-06-15_09:38:24 TasterSteckdose battery: ok
2019-06-15_09:38:24 TasterSteckdose TasterSteckdose_Btn_01 Long
2019-06-15_09:38:25 TasterSteckdose battery: ok
2019-06-15_09:38:25 TasterSteckdose TasterSteckdose_Btn_01 Long
2019-06-15_09:38:25 TasterSteckdose battery: ok
2019-06-15_09:38:25 TasterSteckdose TasterSteckdose_Btn_01 Long
2019-06-15_09:38:25 TasterSteckdose battery: ok
2019-06-15_09:38:25 TasterSteckdose TasterSteckdose_Btn_01 Long
2019-06-15_09:38:25 TasterSteckdose battery: ok
2019-06-15_09:38:25 TasterSteckdose TasterSteckdose_Btn_01 LongRelease
2019-06-15_09:38:28 TasterSteckdose battery: ok
2019-06-15_09:38:28 TasterSteckdose TasterSteckdose_Btn_01 Short
List des Tasters:
Internals:
CUL1_MSGCNT 153
CUL1_RAWMSG A0BE7A0406AA78266234101A7::-98.5:CUL1
CUL1_RSSI -98.5
CUL1_TIME 2019-06-15 09:38:29
DEF 6AA782
FUUID 5cd7de8b-f33f-97d4-f66a-9fd2f813a7fe32da
IODev CUL1
LASTInputDev CUL1
MSGCNT 153
NAME TasterSteckdose
NOTIFYDEV global
NR 57
NTFY_ORDER 50-HM_6AA782
STATE TasterSteckdose_Btn_01 Short
TYPE CUL_HM
chanNo 01
channel_01 TasterSteckdose_Btn_01
channel_02 TasterSteckdose_Btn_02
lastMsg No:E7 - t:40 s:6AA782 d:662341 01A7
protCmdPend 3 CMDs_pending
protLastRcv 2019-06-15 09:38:28
protRcv 127 last_at:2019-06-15 09:38:28
protState CMDs_pending
rssi_at_CUL1 cnt:153 min:-102 max:-59 avg:-86.57 lst:-98.5
READINGS:
2019-05-13 18:50:06 CommandAccepted yes
2019-05-13 18:50:05 D-firmware 1.4
2019-05-13 18:50:05 D-serialNr PEQ1016564
2019-05-12 14:45:47 PairedTo 0xF11234
2019-05-12 11:30:09 R-pairCentral 0xF11234
2019-05-12 14:45:47 RegL_00. 00:00 02:01 0A:F1 0B:12 0C:34
2019-06-15 09:38:28 battery ok
2019-06-15 09:38:28 state TasterSteckdose_Btn_01 Short
cmdStack:
++A001F112346AA78202026623410101
++A001F112346AA78202026623410101
++A001F112346AA78201026623410101
helper:
HM_CMDNR 231
mId 00C2
peerFriend
peerOpt -:pushButton
regLst 0
rxType 28
supp_Pair_Rep 0
ack:
Steckdose TasterSteckdose_Btn_01:E7
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +6AA782,02,00,00
nextSend 1560584309.45527
prefIO
rxt 2
vccu
p:
6AA782
00
00
00
mRssi:
mNo E7
io:
CUL1:
-96.5
-96.5
prt:
bErr 0
sProc 2
sleeping 1
q:
qReqConf 01,02
qReqStat
role:
dev 1
rssi:
at_CUL1:
avg -86.5718954248366
cnt 153
lst -98.5
max -59
min -102
tmpl:
Attributes:
IODev CUL1
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.4
model HM-PB-2-WM55-2
room CUL_HM
serialNr PEQ1016564
subType pushButton
webCmd getConfig:clear msgEvents
Das hier fällt mir auf: protCmdPend 3 CMDs_pending...wie bekomme ich dass weg da ich die letzte Änderung gestern vorgenommen habe...
get hm configCheck ist auch ok
configCheck done:
Habt ihr Ideen?
Muss ich den komplett wieder rauswerfen und neu einlernen oder gibt es einen anderen Befehlt statt on-for-timer wenn man über smartPeer gearbeitet hat?
Danke
Frank
Ganz kurz was mir auffällt (daddel grad nur am Handy):
Der Taster heißt TasterSteckdose, somit auch die Events die du gepostet hast...
Dein Notify (wo es leider KEIN list sondern nur "Text" gibt) soll aber auf HM_6AA782_Btn_02 usw. triggern...
Wie soll das gehen!?
Eventmonitor öffnen und dann gewünschten Event wählen und Notify anlegen lassen...
Die cmds_pending kann viel sein...
Das mal separat angehen...
EDIT: bsser auch noch ein list vom Schaltaktor. Wenn du immer die selbe Einschaltzeit willst, gibt es vielleicht auch ein Register beim Aktor. Dann kannst du auch wieder Peeren... getRegList beim Aktor würde da dann auch helfen...
Gruß, Joachim
ok, danke ich schau mir dass mal durch und melde mich wieder
Topp, dass wars 8)
Hatte "set Tastersteckdose getConfig" gemacht und dann Knöpfchen hinten gedrückt.
Danach die Notifys gelöscht uns sauber neu angelegt mit Hilfe des Eventmonitors.
DANKE!!
Dass einzige wass ich nun noch sehe ist:
configCheck done:
peer not verified. Check that peer is set on both sides
TasterSteckdose_Btn_01 p:Steckdose_Sw
trigger sent to undefined device
triggerUndefined: TasterSteckdose_Btn_02:F11234
An sich läuft ja "scheinbar" alles, die Zeitsteuerung geht, der Taster und die Steckdose.
Aber es ist halt wohl noch nicht "sauber".
Internals:
DEF 66234101
FUUID 5cd67b2f-f33f-97d4-a4ec-a4e8eda8c70a61fc
NAME Steckdose_Sw
NOTIFYDEV global
NR 48
NTFY_ORDER 50-Steckdose_Sw
STATE off
TYPE CUL_HM
chanNo 01
device Steckdose
READINGS:
2019-06-15 10:17:05 CommandAccepted yes
2019-05-06 17:06:53 R-powerUpAction off
2019-05-06 17:06:53 R-sign off
2019-06-14 19:36:27 RegL_01. 00:00 08:00 30:06 56:00 57:24 93:20 94:45
2019-06-15 10:17:17 deviceMsg off (to CUL1)
2019-06-15 10:17:17 level 0
2019-06-15 10:17:17 pct 0
2019-06-15 10:17:17 recentStateType info
2019-06-15 10:17:17 state off
2019-06-15 10:17:17 timedOn off
2019-06-15 10:17:05 trigLast fhem:02
2019-05-24 19:17:38 trig_HM_6AA782_Btn_01 Short_150
2019-05-24 17:22:33 trig_HM_6AA782_Btn_02 Short_73
2019-06-15 10:16:52 trig_TasterSteckdose_Btn_01 Short_182
2019-06-14 19:38:40 trig_TasterSteckdose_Btn_02 Long_82
helper:
dlvlCmd ++A011F112346623410201000000
peerFriend peerSens,peerVirt
peerIDsRaw ,00000000
peerOpt 3:powerMeter
regLst 1,3p
stateUpdatDly 120
expert:
def 1
det 0
raw 1
tpl 0
regCollect:
role:
chn 1
shadowReg:
tmpl:
Attributes:
fhem_widget_channels [{"allowed_values":["off","on"],"alias":"SteckdoseLicht"}]
model HM-ES-PMSW1-PL-DN-R1
peerIDs 00000000,
room HomeMatic
Evtl. noch eine Idee um das aufzuräumen?
Da ist das "ent-peeren" wohl beim Aktor noch nicht (vollständig) angekommen...
Dort mal ein getConfig...
Das andere könnte sein, weil der Taster nun keinen Peer mehr hat...
Evtl. mit einem "virtuellen Button" peeren...
Hast du eine vccu angelegt!? https://wiki.fhem.de/wiki/Virtueller_Controller_VCCUolltest du mal drüber nachdenken...
...bzw. wird empfohlen!
Da gibt es virtuelle Kanäle damit kann man auch peeren, dann ist evtl. auch der Taster "zufrieden"...
Ansonsten bitte noch [gelöst] beim ersten Post davor...
Gruß, Joachim
Eine Anmerkung trotzdem noch ;)
Hast du mal beim Aktor ein:
get Device regList
gemacht?
Wenn es ein Register gibt, wo du eine Einschaltzeit vorgeben kannst (und ich glaube das geht bei einigen/vielen), dann macht das der Aktor automatisch OHNE fhem.
Geht also SICHER(er) aus...
...und du kannst auch wieder direkt peeren: es geht auch OHNE fhem (kann ja immer mal was sein ;) )...
Bei mir läuft alles (was wichtig ist) auch ohne fhem.
fhem macht dann noch ein wenig Komfort oben drauf :)
Daher mische ich bei EINER "Funktion" keine Systeme (wenn nicht muss / bzw. außer die "Funktion" ist nicht [so] wichtig)...
...obwohl ich nat. einige verschiedene habe (Signatur ;) )...
Aber bzgl. beispielsweise Heizung: alles ein System und direkt verknüpft (peering) -> läuft auch ohne fhem
(Haupt)Lichter: dazugehörige Schalter ebenfalls selbes System und direkt verbunden -> läuft auch ohne fhem
Das Licht im Einbauschrank: da wurde wegen Optik ein Fibaro-Auge (ZWave) verwendet aber der Aktor war/ist ein HomeMatik (den wollte ich jetzt nicht ersetzen) das geht NUR MIT FHEM... Nicht schlimm, ist ja nur der Einbauschrank ;)
(bzw. gibt es für den "Notfall" einen HomeMatik Wandtaster: direkt verbunden ;) )
Nur so als Tipp...
(vielleicht für die Zukunft)
Gruß und viel Spaß noch, Joachim
HI,
1) Dort mal ein getConfig... gemacht
configCheck done:
peer not verified. Check that peer is set on both sides
TasterSteckdose_Btn_01 p:Steckdose_Sw
trigger sent to undefined device
triggerUndefined: TasterSteckdose_Btn_02:F11234Muss mann danach an der Steckdose den kleinen knopf noch drücken.
Habe hier immer etwas panik dass ich etwas "zurücksetze" ;-)
2) get Steckdose regList
list: register | range | peer | description
0: confBtnTime | 1 to 255min | | 255=permanent special:permanent
0: intKeyVisib | literal | | visibility of internal channel options:visib,invisib
0: localResDis | literal | | local reset disable options:on,off
0: pairCentral | 0 to 16777215 | | pairing to centralDa ich noch ein ziemlicher newbie bin, was mache ich nun damit?
Heißt die erste Reihe "conBtnTime" dass ich hier immer nach status an ein Laufzeit einschalten kann, also 1-255 Minuten?
Dass wäre perfekt, aber wie mache ich dass dann?
3) Ich habe nur einen CUL-Stick
Zitat von: MadMax-FHEM am 15 Juni 2019, 10:52:55
Hast du eine vccu angelegt!? https://wiki.fhem.de/wiki/Virtueller_Controller_VCCUolltest du mal drüber nachdenken...
...bzw. wird empfohlen!
Gruß, Joachim
PS: Irgendwie glaube ich auch dass es dieses "Steckdose_sw" gar nicht mehr gibt...der List geht nur auf "Steckdose"...
Grüße
Frank
Bei dem brauchst du normalerweise nichts drücken, der hängt ja direkt am Strom und "schläft" nicht.
Bei Batteriegeräten hilft meist ein Drücken -> aufwecken zum "arbeiten" ;)
Der Aktor müsste aber weitere Kanäle haben.
Wenn du auf das "Hauptgerät" gehst in der Detailansicht (es geht auch über list und dann auf den "Namenslink" klicken) solltest du eigentlich alle Kanäle sehen.
Wenn nicht, dann ist wohl was schief...
...oder du hast (aus Versehen) den Schaltkanal so benannt...
...er muss ja nicht _Sw heißen ;)
Evtl. noch mal anlernen oder noch mal ein getConfig (ohne löschen ohne resetten!)...
Ich habe die Schaltsteckdose mit Leistungsmessung auch (folgendes als Model: HM-ES-PMSW1-PL / Vorgängermodell? weil es sieht genauso aus wenn ich bei eq3 nachschaue ;) )...
Und wenn ich beim Schaltkanal (also den _Sw ;) ) ein get regList mache, dann bekomme ich Register, mit denen man wohl eine Einschaltzeit einstellen kann: shOnTime (würde ich mal tippen / mal bei eq3 nachlesen oder im Forum suchen /fragen / evtl. steht auch was in einem der Wiki)...
Zitat
peer not verified. Check that peer is set on both sides
TasterSteckdose_Btn_01 p:Steckdose_Sw
Wenn ich mich nicht täusche bedeutet das soviel wie: irgendwo ist noch ein Peer-Partner eingetragen wo aber die "Gegenstelle" nicht festgestellt werden kann...
...bzw. bei der Gegenstelle nicht klar ist, ob da der passende "zurück-Partner" auch eingetragen ist...
Also entweder steht in einem der Register (also Sensor oder Aktor) der Peer noch drin oder eben nicht mehr drin...
...oder es fehlt (was wahrscheinlicher ist, da es ja heißt: es kann nicht verifiziert werden) noch ein getConfig (Sensor oder Aktor)...
Du kannst auch erst mal eine Zeit warten, vielleicht gibt sich das auch mit der Zeit, wenn dann mal wieder alle Register gelesen wurden: autoReadReg (wenn dort nicht "off" steht, werden ab und an die Register automatisch gelesen, dauert halt)...
Und ich hab in jedem meiner Systeme auch "nur" EIN IO (also HM-CFG-USB bzw. HMUART) aber trotzdem in jedem System eine vccu. Es gibt noch weitere Vorteile als nur die "Ausfallsicherheit" bzw. "Reichweitenvergrößerung" bei Verwendung von mehreren IOs...
Kannst ja im Forum mal suchen bzw. sollte das irgendwo im HomeMatic Wiki auch stehen, wenn nicht sogar bei der vccu selbst...
Gruß, Joachim
Also diese Kanäle sehe ich:
channel_01 Steckdose_Sw
channel_02 Verbrauchsmessung
channel_03 Steckdose_SenPwr
channel_04 Steckdose_SenI
channel_05 Steckdose_SenU
channel_06 Steckdose_SenF
Dass hier finde ich im WIKI:
shOnTime und lgOnTime - das interne on-for-timer von Schaltern oder Dimmern
Die wohl populärsten Register begrenzen die Einschaltzeit eines Aktors. Um z.B. eine Steckdose für 10 sec bei Knopfdruck lokal einzuschalten kann man folgendes programmieren:
set <name> regSet shOnTime 10 self01
shOnTime ist dabei das zuständige Register für die Einschaltzeit bei kurzem (sh=short) Tastendruck, entsprechend gilt lgOnTime für einen langen Tastendruck.
In den Readings werden die Register mit dem jeweiligen verknüpften Taster angezeigt, in unserem Fall also:
R-self01-shOnTime
Der Defaultwert für shOnTime ist 111600 und bedeutet unendlich (von FHEM mit "unused" dargestellt), d.h. die maximale einstellbare Zeit ist 111599 sec (knapp 31 Stunden). So kann man die Zeit löschen:
set <device> regSet shOnTime 111600 self01
oder
set <device> regSet shOnTime unused self01
Übrigens gibt es diese Register auch für die Ausschaltzeit.
Also sollte ja eigtl. unter einem der oben genannen Channels dass "shOnTime" auftauchen oder?
Ich erhalte aber für die einzelnen Chanels immer dass hier:
list: register | range | peer | description
1: sign | literal | | signature (AES) options:on,off
1: statusInfoMinDly | 0.0 to 15.5s | | status message min delay special:unused
1: statusInfoRandom | 0 to 7s | | status message random delay
1: transmitTryMax | 1 to 10 | | max message re-transmit
Zum getconfigcheck -> Einen Fehler konnnte ich beheben, es war wirklich noch ein Peer eingetragen der veraltet war...
Nun siehts so aus:
configCheck done:
trigger sent to undefined device
triggerUndefined: TasterSteckdose_Btn_02:F11234
Wenn ich hier beide vergleiche fällt mir dass hier auf:
TasterSteckdose_Btn_01 Short 1_182 (to Steckdose)
TasterSteckdose_Btn_02 Short 1_100 (to CUL1)
Grüße
Frank
Moin,
get Steckdose_Sw regListliefert nur diese kurze Liste? Kann eigentlich nicht sein.
Poste mal bitte ein list Steckdose
Gruß Otto
Hm, das mit den Registern ist seltsam...
Aber meine Modellnummer ist auch (minimal) anders...
...aber bei mir kommt, wenn ich für die einzelnen Channels das get regList aufrufe deutlich unterschiedliche Register...
Ich daddel grad nur am Handy, da kann ich schlecht nachschauen: was steht beim Attribut expert beim Aktor?
Bzw. setze das doch mal auf "all" (also per DropDown)...
Aber get regList sollte eigentlich unabhängig davon die vollständige Liste liefern...
Entweder unterstützt genau dein Modell das nicht (dann müsste man mal schauen was der Unterschied ist auf den ersten Blick "sahen" sie gleich aus) oder irgendwas ist doch noch schief...
Aber wie geschrieben: wäre halt nur damit du wieder peeren kannst und damit das dann auch ohne laufendes fhem tut (weil der Taster dann direkt an den Aktor sendet und der dann selbsttätig nach der eingestellten Zeit ausgeht)...
Eine Frage noch: wann war dein letztes fhem update? Weil da ist vor einiger Zeit einiges gedreht worden, auch da wo peer smart (was du ja schon hast) eingebaut wurde... Nicht dass du eine "komische Zwischenversion" hast (sieht aber erst mal nicht so aus / sicher ist sicher)
Gruß, Joachim
Meine FHEM Version:
Latest Revision: 19364
Unter Attribute steht bei der Steckdose: 2_raw (kann ich dass ohne Risiko einfach auf 1_allReg ändern?)
Ja. Dann ein getConfig etwas warten und dann mal bitte ein list Steckdose ;)
Zitat von: dudngretl am 16 Juni 2019, 17:02:46
Unter Attribute steht bei der Steckdose: 2_raw (kann ich dass ohne Risiko einfach auf 1_allReg ändern?)
Jep.
Kannst du ja wieder zurückändern, wenn es dir anders besser gefällt/gefallen hat ;)
Ist nur eine "Einstellung" wieviel angezeigt werden soll...
Steht bei mir generell auf "all" weil ich gerne "alles sehe" ;)
Poste doch mal ein list wie von Otto angefragt!
EDIT: noch mal gewünscht hat ;)
Die Versionsnummern, da müsste ich erst mal schauen, war nur für den Fall, dass wir anders nicht weiterkommen...
...weil eben einiges "rumgebaut" wurde und die Angezeigten Register (wie auch Otto schon bemerkt hat) etwas eigenartig dürftig sind...
Gruß, Joachim
Zitat von: Otto123 am 16 Juni 2019, 17:11:15
Ja. Dann ein getConfig etwas warten und dann mal bitte ein list Steckdose ;)
1) eingestellt: expert 3_allReg+raw
2 getConfig Steckdose
3) list Steckdose
Internals:
CUL1_MSGCNT 17663
CUL1_RAWMSG A0EB9A010662341F112340100000000::-84.5:CUL1
CUL1_RSSI -84.5
CUL1_TIME 2019-06-16 19:18:17
DEF 662341
FUUID 5cd67b2f-f33f-97d4-2dfd-826d2d81bf0204b4
IODev CUL1
LASTInputDev CUL1
MSGCNT 17663
NAME Steckdose
NOTIFYDEV global
NR 46
NTFY_ORDER 50-Steckdose
STATE CMDs_done
TYPE CUL_HM
channel_01 Steckdose_Sw
channel_02 Verbrauchsmessung
channel_03 Steckdose_SenPwr
channel_04 Steckdose_SenI
channel_05 Steckdose_SenU
channel_06 Steckdose_SenF
lastMsg No:B9 - t:10 s:662341 d:F11234 0100000000
protCmdDel 151
protLastRcv 2019-06-16 19:18:17
protRcv 17603 last_at:2019-06-16 19:18:17
protResnd 229 last_at:2019-05-26 11:43:57
protResndFail 67 last_at:2019-05-26 10:25:41
protSnd 1120 last_at:2019-06-16 19:18:17
protState CMDs_done
protTimedOn 49 last_at:2019-05-24 18:53:19
rssi_CUL1 cnt:269 min:-105 max:-48 avg:-82.62 lst:-88
rssi_HM_6AA782 cnt:48 min:-98 max:-56 avg:-70.02 lst:-63
rssi_TasterSteckdose cnt:12 min:-75 max:-67 avg:-69.75 lst:-69
rssi_at_CUL1 cnt:17663 min:-108.5 max:-43 avg:-80.2 lst:-84.5
READINGS:
2019-05-26 11:45:46 Activity alive
2019-06-14 19:36:22 CommandAccepted yes
2019-05-25 17:25:45 D-firmware 2.5
2019-05-25 17:25:45 D-serialNr OEQ1974470
2019-06-16 19:18:12 PairedTo 0xF11234
2019-05-11 16:57:34 R-confBtnTime permanent
2019-05-11 17:19:28 R-intKeyVisib invisib
2019-05-06 17:06:52 R-localResDis off
2019-05-11 17:19:28 R-pairCentral 0xF11234
2019-06-16 19:18:12 RegL_00. 00:00 02:01 0A:F1 0B:12 0C:34 15:FF 18:00
2019-05-26 20:00:02 powerOn 2019-05-26 20:00:02
2019-06-16 19:18:17 state CMDs_done
helper:
HM_CMDNR 185
PONtest 0
cSnd 01F1123466234106040000000001,01F112346623410603
mId 00AC
peerFriend
peerOpt -:powerMeter
regLst 0
rxType 1
supp_Pair_Rep 0
expert:
def 1
det 1
raw 1
tpl 0
io:
newChn +662341,00,00,00
nextSend 1560705497.91622
prefIO
rxt 0
vccu
p:
662341
00
00
00
mRssi:
mNo B9
io:
CUL1:
-82.5
-82.5
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
regCollect:
role:
dev 1
prs 1
rpt:
IO CUL1
flg A
ts 1560705497.81726
ack:
HASH(0xfab828)
B98002F1123466234100
rssi:
CUL1:
avg -82.6245353159851
cnt 269
lst -88
max -48
min -105
HM_6AA782:
avg -70.0208333333333
cnt 48
lst -63
max -56
min -98
TasterSteckdose:
avg -69.75
cnt 12
lst -69
max -67
min -75
at_CUL1:
avg -80.2078922040421
cnt 17663
lst -84.5
max -43
min -108.5
shadowReg:
tmpl:
Attributes:
IODev CUL1
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
expert 3_allReg+raw
firmware 2.5
icon black_Steckdose.off
model HM-ES-PMSW1-PL-DN-R1
room CUL_HM
serialNr OEQ1974470
subType powerMeter
webCmd getConfig:clear msgEventsget Steckdose_Sw regList:
list: register | range | peer | description
1: sign | literal | | signature (AES) options:on,off
1: statusInfoMinDly | 0.0 to 15.5s | | status message min delay special:unused
1: statusInfoRandom | 0 to 7s | | status message random delay
1: transmitTryMax | 1 to 10 | | max message re-transmitget Steckdose regList
list: register | range | peer | description
0: confBtnTime | 1 to 255min | | 255=permanent special:permanent
0: intKeyVisib | literal | | visibility of internal channel options:visib,invisib
0: localResDis | literal | | local reset disable options:on,off
0: pairCentral | 0 to 16777215 | | pairing to central
Moin,
mal sehen ob Martin dazu was sagen kann, aber aus meiner Sicht fehlen da alle Register die pro Peer gesetzt werden können. Jetzt könnte man meinen, die kommen erst wenn gepeert. Bei mir sind die aber immer alle sichtbar. Aktiviere doch mal die Anzeige des internen Peer.
set Steckdose regSet intKeyVisib visib
Und mach dann nochmal ein regList.
Gruß Otto
hier gibt es ein problem mit der model-id (mid).
das list zeigt mid=00AC und attr model HM-ES-PMSW1-Pl-DN-R1. attr model ist also falsch, müsste HM-ES-PMSw1-Pl sein.
mein hminfo (get hminfo models -f ES) zeigt folgende models:
models filtered:ES
subType name ID supportedMode Info List channels
powerMeter HM-ES-PMSw1-DR 00EA normal 00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
powerMeter HM-ES-PMSw1-Pl 00AC normal 00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
powerMeter HM-ES-PMSw1-Pl-DN-R1 00D7 normal 00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
powerMeter HM-ES-PMSw1-Pl-DN-R2 00E2 normal 00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
powerMeter HM-ES-PMSw1-Pl-DN-R3 00E3 normal 00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
powerMeter HM-ES-PMSw1-Pl-DN-R4 00E4 normal 00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
powerMeter HM-ES-PMSw1-Pl-DN-R5 00E5 normal 00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
powerMeter HM-ES-PMSw1-SM 00F6 normal 00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
powerSensor HM-ES-TX-WM 00DE config,wakeup 00:10 1 1-2 IEC,
hast du attr model selbst gesetzt oder wurde es von autocreate angelegt?
Zitat von: Otto123 am 17 Juni 2019, 09:06:21
Moin,
mal sehen ob Martin dazu was sagen kann, aber aus meiner Sicht fehlen da alle Register die pro Peer gesetzt werden können. Jetzt könnte man meinen, die kommen erst wenn gepeert. Bei mir sind die aber immer alle sichtbar. Aktiviere doch mal die Anzeige des internen Peer.
set Steckdose regSet intKeyVisib visib
Und mach dann nochmal ein regList.
Gruß Otto
Gemacht, kommt immer noch dass:
list: register | range | peer | description
0: confBtnTime | 1 to 255min | | 255=permanent special:permanent
0: intKeyVisib | literal | | visibility of internal channel options:visib,invisib
0: localResDis | literal | | local reset disable options:on,off
0: pairCentral | 0 to 16777215 | | pairing to centralZitat von: frank am 17 Juni 2019, 13:13:52
hast du attr model selbst gesetzt oder wurde es von autocreate angelegt?
Ich habe das nicht selbst gemacht, sondern wie die anderen HM Komponenten auch "angelernt" wie in den WIKIS beschrieben.
Also hmpairforsec und dann Knöpfchen gedrückt.
was zeigt denn bei dir "get hminfo models -f ES"?
:'(
Please define hminfo first
Ich hatte dass eigtl. damals nach der Anleitung (https://wiki.fhem.de/wiki/HomeMatic_HMInfo) eingerichtet...
"get hm help" geht...
Unknown argument choose one of
---checks---
get configCheck [-typeFilter-] # perform regCheck and regCheck
get regCheck [-typeFilter-] # find incomplete or inconsistant register readings
get peerCheck [-typeFilter-] # find incomplete or inconsistant peer lists
---actions---
set saveConfig [-typeFilter-] [-file-] # stores peers and register with saveConfig
set archConfig [-a] [-file-] # as saveConfig but only if data of entity is complete
set purgeConfig [-file-] # purge content of saved configfile
set loadConfig [-typeFilter-] -file- # restores register and peer readings if missing
set verifyConfig [-typeFilter-] -file- # compare curent date with configfile,report differences
set autoReadReg [-typeFilter-] # trigger update readings if attr autoReadReg is set
set tempList [-typeFilter-][save|restore|verify|status|genPlot][-filename-]# handle tempList of thermostat devices
set x-deviceReplace <old device> # WARNING:replace a device with another
---infos---
set update # update HMindfo counts
get register [-typeFilter-] # devicefilter parse devicename. Partial strings supported
get peerXref [-typeFilter-] # peer cross-reference
get models [-typeFilter-] # list of models incl native parameter
get protoEvents [-typeFilter-] [short|all|long] # protocol status - names can be filtered
get msgStat # view message statistic
get param [-typeFilter-] [-param1-] [-param2-] ... # displays params for all entities as table
get rssi [-typeFilter-] # displays receive level of the HM devices
last: most recent
avg: average overall
range: min to max value
count: number of events in calculation
---clear status---
set clear[G] [-typeFilter-] [msgEvents|readings|msgStat|register|rssi]
# delete readings selective
msgEvents # delete all protocol-events , msg events
msgErrors # delete protoevents for all devices which had errors
readings # all readings
register # all register-readings
oldRegs # outdated register (cleanup)
rssi # all rssi data
msgStat # message statistics
trigger # trigger readings
attack # attack related readings
all # all of the above
---help---
get help #
***footnote***
[-nameFilter-] : only matiching names are processed - partial names are possible
[-modelsFilter-] : any match in the output are searched.
set cpRegs -src:peer- -dst:peer-
copy register for a channel or behavior of channel/peer
set templateDef -templateName- -param1[:-param2-...] -description- -reg1-:-val1- [-reg2-:-val2-] ...
define a template
set templateSet -entity- -templateName- -peer:[long|short]- [-param1- ...]
write register according to a given template
set templateDel -entity- -templateName- -peer:[long|short]-
remove a template set
set templateExe -templateName-
write all assigned templates to the file
get templateUsg -templateName-[sortPeer|sortTemplate]
show template usage
get templateChk [-typeFilter-] -templateName- -peer:[long|short]- [-param1- ...]
compare whether register match the template values
get templateList [-templateName-] # gives a list of templates or a description of the named template
list all currently defined templates or the structure of a given template
======= typeFilter options: supress class of devices ====
set -name- -cmd- [-dcasev] [-f -filter-] [params]
entities according to list will be processed
d - device :include devices
c - channels :include channels
i - ignore :include devices marked as ignore
v - virtual :supress fhem virtual
p - physical :supress physical
a - aktor :supress actor
s - sensor :supress sensor
e - empty :include results even if requested fields are empty
-f - filter :regexp to filter entity names
Wieder ein dummer Anwenderfehler?
hminfo ist der Modulname und dein define heisst hm? :)
Dann alles gut get hm models -f ES
Ui, und schon geht's ;D
Tablet-UI
Anwesenheit
Aussen
BMA
Bügelzimmer
CUL_HM
FritzBox
HomeMatic
Logfiles
Rollladen
Sensoren
System
Text2Speech
Unsorted
Wohnzimmer
Everything
Logfile
Commandref
Remote doc
Edit files
Select style
Event monitor
models filtered:ES
subType name ID supportedMode Info List channels
powerMeter HM-ES-PMSW1-DR 00EA normal 00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
powerMeter HM-ES-PMSW1-PL 00AC normal 00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
powerMeter HM-ES-PMSW1-PL-DN-R1 00D7 normal 00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
powerMeter HM-ES-PMSW1-PL-DN-R2 00E2 normal 00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
powerMeter HM-ES-PMSW1-PL-DN-R3 00E3 normal 00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
powerMeter HM-ES-PMSW1-PL-DN-R4 00E4 normal 00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
powerMeter HM-ES-PMSW1-PL-DN-R5 00E5 normal 00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
powerMeter HM-ES-PMSW1-SM 00F6 normal 00:10 1,1,3p.4p.5p.6p 1 Sw, 2 Pwr, 3 SenPwr, 4 SenI, 5 SenU, 6 SenF,
powerSensor HM-ES-TX-WM 00DE config,wakeup 00:10 1 1-2 IEC,
seltsam. sieht aus wie bei mir.
welches model steht denn auf der rückseite des gerätes gedruckt?
Moin.
Auf der Rücksteite steht:
eQ-3
HM-ES-PMSw1-PI-DN-R1
Power meter switch actuator
Gruß
ok, also voodoo. 8)
ich habe jetzt mal über meinen HM-ES-PMSw1-Pl (gehäuseaufdruck) mit seriennummer "drübergepairt".
2019.06.18 09:07:34.759 0 : HMLAN_Parse: hmlan1 R:E24AF1D stat:0000 t:863FA201 d:FF r:FFA9 m:02 8000 24AF1D 1ACE1F 2500AC4B455130393637313033513F0100
2019.06.18 09:07:34.885 3 : Device SwitchES01 added to ActionDetector with 000:10 time
2019.06.18 09:07:34.894 3 : CUL_HM pair: SwitchES01 powerMeter, model HM-ES-PMSw1-Pl serialNr KEQ0967103
das device sendet 00AC in der anlernmessage und fhem "übetsetzt" die mid korrekt in HM-ES-PMSw1-Pl.
ausserdem wurde beim drüberpairen intKeyVisib auf invisible geändert. dadurch waren auch sämtliche hinweise über das vorhandene interne peering im sw-channel verschwunden. get regList zeigt aber mögliche peerregister.
paire auch mal "drüber" und poste die vergleichbaren zeilen aus fhem.log.
attr global verbose 3
attr CUL1 verbose 4
set CUL1 hmPairSerial OEQ1974470
Ok. Nur auf Nummer sicher...
Mit drüber pairen meinst du die drei Zeilen die du unten aufgeführt hats und nicht hmpaitfoesec und dann knöpfchen?
Gruß
genau, meine zeilen sollten genügen.
allerdings im hauptdevice beobachten, ob irgendwann cmds_done erreicht wird. wenn das loggen erfolgreich war, kannst du die verbose attribute wieder löschen (default), oder auf deine alten werte zurück setzen.
Ist erledigt:
2019.06.19 19:17:51 4: CUL_Parse: CUL1 A 14 4C 845E 662341 000000 80DDA1000000000008F9FEE6 -87
2019.06.19 19:17:59 4: CUL_Parse: CUL1 A 1A 01 8000 662341 F11234 2500D74F455131393734343730513F0100E5 -87.5
2019.06.19 19:17:59 3: Device Steckdose added to ActionDetector with 000:10 time
Das hier habe ich übrigens eben gesehen im FHEM.LOG:
2019.06.18 03:30:00 3: CUL_HM set Steckdose_Sw on-for-timer 1800
2019.06.18 03:30:04 3: CUL1: Unknown code ERR:CCA, help me!
2019.06.18 03:30:05 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL1)
2019.06.18 03:30:09 3: Setting CUL1 serial parameters to 38400,8,N,1
2019.06.18 03:30:09 3: CUL1: Possible commands: ABbCeFGhiKkLlMmNRTtUuVWXxYZ
2019.06.18 03:30:09 1: /dev/ttyACM0 reappeared (CUL1)
Ist zum ersten mal aufgetreten...
ok, wenigstens sendet der aktor das, was auf dem gehäuse steht. mId => 00D7.
bleibt der voodoo, wie kam mId=00AC in dein device.
attr modelForce hast du auch nie benutzt?
wurde mId nun auch im list geändert?
wenn nicht würde ich das device in fhem löschen und neu anlegen.
was ist nun mit get regList in chn1?
cca:
der cul konnte nicht senden, da er gerade viel zu empfangen hatte. kann man auch viel im forum finden: zb
https://forum.fhem.de/index.php/topic,56198.msg477558.html#msg477558 (https://forum.fhem.de/index.php/topic,56198.msg477558.html#msg477558)
für homematic gilt grundsätzlich:
ein cul mit culfw / a-culfw ist 3. wahl,
mit ts_culfw 2. wahl,
und ein homematic io 1. wahl.
störungen konnen aber alle betreffen, auch die devices.
OK, danke - bin jetz dann immer wieder unterwegs und werde mir dass dann danach anschauen, prinzipiell läufts ja (noch)...
Zitat von: frank am 20 Juni 2019, 09:20:34
für homematic gilt grundsätzlich:
ein cul mit culfw / a-culfw ist 3. wahl,
mit ts_culfw 2. wahl,
und ein homematic io 1. wahl.
Hierzu hätte ich zwei Fragen:
1) Meinst du mit "homematic io" dann Homematic Smart Home Zentrale CCU3 oder CCU2 und dass dann zusätzlich an FHEM statt meinem CUL-Stick?
2) Ich hatte damals den CUL Stick genommen da ich im Internet gelesen hatte, bei den Zentralen (CCU2...) geht Kommunikation nach "draussen" also über irgendwelche Server ähnlich wie bei SOMFY o.ä. Dass wollte ich nicht da ich alles nur im internen Netz haben möchte und nicht über "CHINA oder US-Server". Stimmt dass dann nicht? Dann würde ich mich hier einmal einlesen und evtl. einen Abtausch anpeilen...
Grüße und Danke
Zitat von: dudngretl am 20 Juni 2019, 19:58:49
OK, danke - bin jetz dann immer wieder unterwegs und werde mir dass dann danach anschauen, prinzipiell läufts ja (noch)...
Hierzu hätte ich zwei Fragen:
1) Meinst du mit "homematic io" dann Homematic Smart Home Zentrale CCU3 oder CCU2 und dass dann zusätzlich an FHEM statt meinem CUL-Stick?
2) Ich hatte damals den CUL Stick genommen da ich im Internet gelesen hatte, bei den Zentralen (CCU2...) geht Kommunikation nach "draussen" also über irgendwelche Server ähnlich wie bei SOMFY o.ä. Dass wollte ich nicht da ich alles nur im internen Netz haben möchte und nicht über "CHINA oder US-Server". Stimmt dass dann nicht? Dann würde ich mich hier einmal einlesen und evtl. einen Abtausch anpeilen...
Grüße und Danke
Vermutlich eher ein richtiges HM-IO wie beispielsweise: https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi
(bzw. sollten im Homematic Wiki weitere stehen)
Eine Anbindung per CCU geht nat. auch, ist Funk-technisch auch gut (ist ja auch "alles" Homematic) ALLERDINGS: Einbindung in fhem ist ANDERS!!
Das geht dann per HMCCU-Modul!
EDIT: es muss keine Kommunikation nach außen erfolgen, wenn man eine CCU verwendet! Man kann das auch lokal betreiben...
Gruß, Joachim
Hi,
die CCU ist kein IO im Sinne von FHEM. Die CCU ist eine eigene Zentrale, also eher so etwas wie FHEM mit Einschränkung "Nur für Homematic".
Im Wiki gibt es einen Abschnitt für Homematic, dort findest Du die IOs
Gruß Otto
Danke euch!