HM-Sec-SC-2 Schaltbefehle werden nach Update nicht mehr ausgeführt

RoqueNublo · 11 Juli 2014, 16:48:34

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

martinp876 · 11 Juli 2014, 18:06:27

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?

RoqueNublo · 11 Juli 2014, 18:48:55

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

martinp876 · 11 Juli 2014, 19:02:24

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).

RoqueNublo · 11 Juli 2014, 19:36:29

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

martinp876 · 11 Juli 2014, 20:19:54

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?

RoqueNublo · 13 Juli 2014, 14:41:40

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