Hi,
ich habe heute einen Update durchgeführt, seither werden Schaltvorgänge meines HM-Sec-SC-2 zwar bestätigt orange/grün aber nicht ausgeführt.
fhem.cfg
HM-Sec-SC-2:
define HM_TFK CUL_HM 26B7C6
attr HM_TFK room HMTFK
define FileLog_HM_TFK FileLog ./log/HM_TFK-%Y.log HM_TFK
attr FileLog_HM_TFK logtype text
attr FileLog_HM_TFK room HMTFK
Dummy:
define VirtDev CUL_HM 112233
attr VirtDev autoReadReg 4_reqStatus
attr VirtDev expert 2_full
attr VirtDev model virtual_2
attr VirtDev peerIDs 1
attr VirtDev room VirtDev
attr VirtDev subType virtual
attr VirtDev IODev hmusb
define VirtDev_Btn1 CUL_HM 11223301
attr VirtDev_Btn1 model virtual_2
attr VirtDev_Btn1 peerIDs 1
attr VirtDev_Btn1 webCmd press short:press long
attr VirtDev_Btn1 room VirtDev
:
Meldungen im LogFile
bisher:
2014-07-11_10:15:52 HM_TFK open
2014-07-11_10:15:52 HM_TFK contact: open (to hmusb)
2014-07-11_10:17:01 HM_TFK closed
2014-07-11_10:17:01 HM_TFK contact: closed (to hmusb)
seither:
2014-07-11_13:46:12 HM_TFK trigDst_424242: noConfig
2014-07-11_13:47:13 HM_TFK trigDst_424242: noConfig
hat jemand einen Tip für mich?
Gruß Roque
netter teil deiner config.
Sicher ist dir klar, dass ich weder den Room noch das Logfile des SC-2 benötige.
der HM_TFK sendet einenTrigger an den hmusb - dieser sollte automatisch antworten.
FHEM zeichnet neuerdings auf, wenn ein Sensor ein Device, triggern will der Peer aber nicht bekannt ist. Dein SC sendet an 424242 - was immer das ist.
Zitatseither werden Schaltvorgänge meines HM-Sec-SC-2 zwar bestätigt orange/grün aber nicht ausgeführt.
und jetzt soll ich mir überlegen, was bei dir zu schalten ist?
define VirtDev CUL_HM 112233
attr VirtDev autoReadReg 4_reqStatus # macht keinen sinn - gibt es bei virtuellen Aktoren nicht
attr VirtDev expert 2_full # macht keinen sinn - gibt es bei virtuellen Aktoren nicht
attr VirtDev model virtual_2
attr VirtDev peerIDs 1 # devices haben keine Peers - löschen!
attr VirtDev room VirtDev
attr VirtDev subType virtual
attr VirtDev IODev hmusb
define VirtDev_Btn1 CUL_HM 11223301
attr VirtDev_Btn1 model virtual_2
attr VirtDev_Btn1 peerIDs 1 # peerID 1? Das MUSS 8-stelling sein - wo it das her?
Hi Martin,
ich habe den HM-Sec-SC-2 (define HM_TFK ..) mit dem hmusb (define hmusb HMLAN ...) gepaired, dann ein virtuelles Device (define VirtDev ...) eingerichtet und anschließend mit dem HM_TFK gepeered. Über VirtDev habe ich eine Anzeige im Floorplan realisiert. Bisher lief alles wie gewünscht, d.h. bis zum Update heute.
Was kann ich Dir zur Verfügung stellen, damit Du helfen kannst?
Gruß Roque
424242 ist die hmId des hmusb HMLAN
define hmusb HMLAN 127.0.0.1:1234
attr hmusb hmId 424242
attr hmusb hmLanQlen 1_min
attr hmusb logIDs sys,all
attr hmusb room HMUSB
das SC scheint mit nicht mit dem virtuellen Device gepeert. Es sendet nicht dort hin - da fehlt ein (to 'dummy')
Als lese einmal die configuration deines SC aus, damit du sehen kannst, womit der gepeert ist (wahrscheinlich garnicht oder mit HMLAN).
was soll dann ausgewertet werden? Der State des dummy, der status des SC oder ein notify? Da hast du doch etwas eingerichtet - oder willst etwas sehen - was?
Der VirtDev_Btn1 ist mit nichts gepeert - sollte er mit dem SC gepeert sein? dann müsste dies auch in der Peerlist erscheinen. Das kannst du nachholen (virtBtn, SC oder beide).
Hi, ausgewertet habe ich (ich hoffe es jedenfalls) bisher lediglich das state aus dem dummy (VirtDev). Für meine HomeMatic Komponenten habe ich bisher noch keine Notify's angelegt.
- attr VirtDev_Btn1 devStateIcon open:Eingang.off:closed closed:Eingang.on:open
- attr VirtDev_Btn1 fp_Erdgeschoss 283,326,0,
Sorry, deinen Hinweis auf ,,to 'dummy'" verstehe ich nicht, kannst Du mir bitte einen Tip geben wo ich nachlesen kann.
Nachfolgende Info aus /log/.save
setstate hmusb opened
setstate hmusb 2014-07-04 17:51:09 prot_timeout last
setstate hmusb 2014-07-07 16:02:44 prot_ERROR-Overload last
setstate hmusb 2014-07-07 15:42:51 prot_Warning-HighLoad last
setstate hmusb 2014-07-11 16:42:50 prot_disconnected last
setstate hmusb 2014-07-11 16:42:50 prot_init last
setstate hmusb 2014-07-11 16:42:55 Xmit-Events ok:1
setstate hmusb 2014-07-11 16:42:55 cond ok
setstate hmusb 2014-07-11 16:42:55 prot_ok last
setstate HM_TFK closed
setstate HM_TFK 2014-07-10 22:13:47 .D-devInfo 810101
setstate HM_TFK 2014-07-10 22:13:47 .D-stc 80
setstate HM_TFK 2014-07-10 22:13:47 Activity alive
setstate HM_TFK 2014-07-10 22:13:47 D-firmware 2.4
setstate HM_TFK 2014-07-10 22:13:47 D-serialNr LEQ0137569
setstate HM_TFK 2014-07-10 22:14:15 R-VirtDevTFK_Btn1-expectAES set_off
setstate HM_TFK 2014-07-10 22:14:15 R-VirtDevTFK_Btn1-peerNeedsBurst set_off
setstate HM_TFK 2014-07-10 22:15:34 alive yes
setstate HM_TFK 2014-07-10 22:15:34 battery ok
setstate HM_TFK 2014-07-10 22:15:34 cover closed
setstate HM_TFK 2014-07-10 22:15:34 recentStateType info
setstate HM_TFK 2014-07-11 10:17:01 contact closed (to hmusb)
setstate HM_TFK 2014-07-11 10:17:01 state closed
setstate HM_TFK 2014-07-11 15:01:01 .protLastRcv 2014-07-11 15:01:01
setstate HM_TFK 2014-07-11 15:01:01 trigDst_424242 noConfig
setstate VirtDev CMDs_done
setstate VirtDev 2014-07-11 16:26:47 state CMDs_done
setstate VirtDev_Btn1 set_press short
setstate VirtDev_Btn1 2014-07-11 16:26:47 state set_press short
nach dem Update entnommen. Ich Frage mich warum es schon klappte, wenn es doch keine Verbindungen gibt bzw. gab.
Gruß Roque
ZitatSorry, deinen Hinweis auf ,,to 'dummy'" verstehe ich nicht, kannst Du mir bitte einen Tip geben wo ich nachlesen kann.
2014-07-11_10:15:52 HM_TFK contact: open (to
hmusb)
hier sendet der HM_TFK an hmusb. Er sendet nie (in den gelieferten Logs) an VirtDev_Btn1.
Zitat- attr VirtDev_Btn1 devStateIcon open:Eingang.off:closed closed:Eingang.on:open
- attr VirtDev_Btn1 fp_Erdgeschoss 283,326,0,
hm - das bringt garnichts.
warum sendest du nicht ein list den VirtDev_Btn1 mit allen Attributen? Aber lass einmal
ZitatHM_TFK R-VirtDevTFK_Btn1-expectAES set_off
HM_TFK R-VirtDevTFK_Btn1-peerNeedsBurst set_off
deuted auf ein peering hin - aber der peer selbst wird nicht angezeigt.
Zitat. Ich Frage mich warum es schon klappte, wenn es doch keine Verbindungen gibt bzw. gab.
das sind eben die Fragen - was klappt und welche Verbindung sollte es geben?
Wenn du auswerten willst, wie er Zustand des SC ist, warum nutzt du nicht den State des SC?
Was ausser Anzeigen willst du noch machen? Der Dummy muss doch nur ein ack senden (wenn er gepeert ist).
Was u.a. nicht zu sehen ist, der HM_TFK sollte ein Attribut subType haben ( und einige mehr, z.B. model). ist dir da etwas verloren gegangen?
Problem gelöst mit nachfolgend beschriebener Vorgehensweise
Step 1: IO-Device in den Pairing-Modus versetzen
- set hmusb hmPairForSec 600 # oder
- set hmusb hmPairSerial LEQ0xxxxxx
danach entsprechend Handbuch, Stichwort "anlernen" verfahren.
Step 2: Pairing verifizieren
- ReadingInfo HM_TFK ,,R-pairCentral 0x424242"
Step 3: Status prüfen, ob Pairing OK
- set HM_TFK getConfig
- get HM_TFK saveConfig ./log/TFK.tmp
#======== store device data:HM_TFK === from: 2014-07-13 12:29:38
#--- entity:HM_TFK
setreading HM_TFK D-firmware 2.4
setreading HM_TFK D-serialNr LEQ0137569
setreading HM_TFK .D-devInfo 810101
setreading HM_TFK .D-stc 80
# Peer Names:
set HM_TFK peerBulk 00000000,
set HM_TFK regBulk RegL_00: 02:01 09:00 0A:42 0B:42 0C:42 10:01 14:06 00:00
set HM_TFK regBulk RegL_01: 08:00 20:60 21:00 22:64 30:06 00:00
# timestamp of the readings for reference
# :peerList
# 2014-07-13 12:26:22 :RegL_00:
# 2014-07-13 12:26:23 :RegL_01:
======= finished ===
Step 4: Virtuellen Aktor anlegen (FHEM-Web Oberfläche / Kommandozeile eingeben)
- define VirtAktor CUL_HM 224466
- set VirtAktor virtual 1
Ergebnis: (laut Wiki wurde damit ein Virtuellen Aktor mit einem Kanal erstellt)
define VirtAktor CUL_HM 224466
attr VirtAktor autoReadReg 4_reqStatus
attr VirtAktor expert 2_full
attr VirtAktor model virtual_2
attr VirtAktor peerIDs
attr VirtAktor room HMVIR
attr VirtAktor subType virtual
attr VirtAktor webCmd virtual
define VirtAktor_Btn1 CUL_HM 22446601
attr VirtAktor_Btn1 model virtual_2
attr VirtAktor_Btn1 peerIDs
attr VirtAktor_Btn1 webCmd press short:press long
#======== store device data:VirtAktor === from: 2014-07-13 12:56:02
#--- entity:VirtAktor
# timestamp of the readings for reference
#--- entity:VirtAktor_Btn1
# timestamp of the readings for reference
======= finished ===
Step 5: HM_TFK verbinden mit VirtAktor
- set HM_TFK peerChan 0 VirtAktor_Btn1 single set
- set HM_TFK getConfig # zweimal durchgeführt
Problem gelöst durch WikiInfo:
,,Am Ende unbedingt einmal "Save config" drücken, damit der virtuelle Aktor in der fhem.cfg abgespeichert wird."
#======== store device data:HM_TFK === from: 2014-07-13 13:02:29
#--- entity:HM_TFK
setreading HM_TFK D-firmware 2.4
setreading HM_TFK D-serialNr LEQ0137569
setreading HM_TFK .D-devInfo 810101
setreading HM_TFK .D-stc 80
# Peer Names:VirtAktor_Btn1,
set HM_TFK peerBulk 00000000,22446601,
# timestamp of the readings for reference
# VirtAktor_Btn1, :peerList
======= finished ===
Problem gelöst.
Gruß Roque