Hallo,
ich würde mir gern den HB-UNI-SenAct-8-8 von hier nachbauen. https://github.com/jp112sdl/HB-UNI-SenAct-8-8 (https://github.com/jp112sdl/HB-UNI-SenAct-8-8)
Kann mir evtl. jemand sagen ob der 8 Fach aktor in Fehm erkannt wird und funktioniert?
Danke und Gruß
Nein - ist nicht im Addin https://github.com/pa-pa/AskSinPP/tree/master/examples/custom/contrib/FHEM
Schade. Gibt es eine andere Möglichkeit einen 8-fach Aktor zu realisieren? Ich habe nämlich ein 8-relaisboard das ich über HM einbinden möchte.
Man könnte es auch mit aufnehmen. Müsste halt mal jemand machen - am besten nen PullRequest.
Ich würde ja da gern helfen. Aber was heißt pull request :-[
Welches Gerät soll es denn genau sein ?
HB-UNI-SenAct-8-8-RC oder HB-UNI-SenAct-8-8-SC
Ich bräuchte den SC um ein 8fach Relais Board anzusteuern.
Probiere mal das angepasste Addon. Ich habe das aber nicht weiter getestet - keine Hardware da.
https://github.com/pa-pa/AskSinPP/tree/master/examples/custom/contrib/FHEM
Super, danke. Hardware hab ich da muss ich aber erst noch zusammenbasteln. Ich melde wenn ich soweit bin. Könnte aber etwas dauern. Aber vielen dank schon mal. :D
Hallo,
ich habe die Hardware nun mal zusammengesteckt und Deine angepasste "HMConfig_AskSinPPCustom.pm" ins Fhem-Verzeichnis kopiert.
Das Device wird mit 8 Sensing Kanälen und 8 Aktoren erkannt.
Internals:
CFGFN
DEF F33A01
FUUID 5dd18e6e-f33f-04c6-12f0-f76411f96863f3d5
IODev nanoCUL_868MHz
LASTInputDev nanoCUL_868MHz
MSGCNT 94
NAME HM_F33A01
NOTIFYDEV global
NR 3686
STATE CMDs_done
TYPE CUL_HM
channel_01 HM_F33A01_Sw_01
channel_02 HM_F33A01_Sw_02
channel_03 HM_F33A01_Sw_03
channel_04 HM_F33A01_Sw_04
channel_05 HM_F33A01_Sw_05
channel_06 HM_F33A01_Sw_06
channel_07 HM_F33A01_Sw_07
channel_08 HM_F33A01_Sw_08
channel_09 HM_F33A01_Sen_01
channel_0A HM_F33A01_Sen_02
channel_0B HM_F33A01_Sen_03
channel_0C HM_F33A01_Sen_04
channel_0D HM_F33A01_Sen_05
channel_0E HM_F33A01_Sen_06
channel_0F HM_F33A01_Sen_07
channel_10 HM_F33A01_Sen_08
lastMsg No:3D - t:10 s:F33A01 d:F11111 0601000048
nanoCUL_868MHz_MSGCNT 94
nanoCUL_868MHz_RAWMSG A0E3DA210F33A01F111110601000048::-57.5:nanoCUL_868MHz
nanoCUL_868MHz_RSSI -57.5
nanoCUL_868MHz_TIME 2019-11-17 19:21:57
protLastRcv 2019-11-17 19:21:57
protRcv 94 last_at:2019-11-17 19:21:57
protResnd 1 last_at:2019-11-17 19:16:49
protSnd 87 last_at:2019-11-17 19:21:57
protState CMDs_done
rssi_at_nanoCUL_868MHz cnt:95 min:-86 max:-56.5 avg:-64.84 lst:-57.5
rssi_nanoCUL_868MHz cnt:18 min:-96 max:-60 avg:-69.5 lst:-72
READINGS:
2019-11-17 19:16:40 CommandAccepted yes
2019-11-17 19:21:25 D-firmware 1.0
2019-11-17 19:21:25 D-serialNr JPSENACT01
2019-11-17 19:16:43 PairedTo 0xF11111
2019-11-17 19:16:43 R-cyclicInfoMsg on
2019-11-17 19:16:43 R-pairCentral 0xF11111
2019-11-17 19:16:43 R-sabotageMsg on
2019-11-17 19:16:43 RegL_00. 00:00 02:01 09:01 0A:F1 0B:11 0C:11 10:01
2019-11-17 19:21:57 state CMDs_done
helper:
HM_CMDNR 61
cSnd 01F11111F33A010103,11F11111F33A010201000000
mId F33A
peerFriend
peerOpt -:custom
regLst 0
rxType 20
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +F33A01,00,00,00
nextSend 1574014917.45839
prefIO
rxt 2
vccu
p:
F33A01
00
00
00
mRssi:
mNo 3D
io:
nanoCUL_868MHz:
-51.5
-51.5
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
regCollect:
role:
dev 1
prs 1
rpt:
IO nanoCUL_868MHz
flg A
ts 1574014917.36006
ack:
HASH(0x44f5008)
3D8002F11111F33A0100
rssi:
at_nanoCUL_868MHz:
avg -64.8473684210527
cnt 95
lst -57.5
max -56.5
min -86
nanoCUL_868MHz:
avg -69.5
cnt 18
lst -72
max -60
min -96
shadowReg:
tmpl:
Attributes:
IODev nanoCUL_868MHz
IOgrp VCCU1:nanoCUL_868MHz
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
model HB-UNI-SenAct-8-8-SC
room CUL_HM
serialNr JPSENACT01
subType custom
webCmd getConfig:clear msgEvents
Die Sensingkanäle werden auch übertragen, sprich close/open. Je nachdem ob ich einen Taster drücke oder nicht.
Die Aktoren funktionieren aber nicht. Nicht funtionieren heißt, das beim Druck auf die Lampe in Fhem direkt die Lampe mit Ausrufezeichen erscheint.
Hier mal ein Listing von einem Kanal
Internals:
CFGFN
DEF F33A0101
FUUID 5dd18e6e-f33f-04c6-36d0-9b708ad5ec4da222
NAME HM_F33A01_Sw_01
NOTIFYDEV global
NR 3688
STATE off
TYPE CUL_HM
chanNo 01
device HM_F33A01
READINGS:
2019-11-17 19:21:25 CommandAccepted yes
2019-11-17 19:16:43 R-sign off
2019-11-17 19:20:13 RegL_01. 00:00 08:00 30:06 56:00 57:24
2019-11-17 19:24:35 deviceMsg .off. (to VCCU1)
2019-11-17 19:24:35 level 0 %
2019-11-17 19:24:35 pct 0
2019-11-17 19:24:35 recentStateType info
2019-11-17 19:24:35 state off
2019-11-17 19:24:35 timedOn off
2019-11-17 19:21:25 trigLast fhem:02
helper:
dlvl 00
dlvlCmd ++A011F11111F33A010201000000
peerFriend peerAct,peerVirt
peerIDsRaw ,00000000
peerOpt 3:custom,4:custom
regLst 1,3p,4p,4pp,4ppp,4pppp,4ppppp,4pppppp,4ppppppp
expert:
def 1
det 0
raw 1
tpl 0
regCollect:
role:
chn 1
shadowReg:
tmpl:
Attributes:
model HB-UNI-SenAct-8-8-SC
peerIDs 00000000,
Ich bin mir momentan aber nicht sicher ob es an meinem Aufbau liegt oder an Fhem. Der PCF8574 wird zumindest mal erkannt. Er hat die Adresse 0x27. Das habe ich mit einem anderen Test sketch herausgefunden. Die Adresse habe ich im Code dann an dieser Stelle geändert
#define PCF8574_ADDRESS 0x27
#define RELAY_PIN_1 0
#define RELAY_PIN_2 1
#define RELAY_PIN_3 2
#define RELAY_PIN_4 3
#define RELAY_PIN_5 4
#define RELAY_PIN_6 5
#define RELAY_PIN_7 6
#define RELAY_PIN_8 7
#define RELAY_ON_STATE_INVERT true
So, wie komme ich dem Problem jetzt auf die Schliche. Kann ich dem Arduino auch ohne Fhem sagen das er mal den Kanal 1 schalten soll um zu sehen ob mein Aufbau prinzipiell funktioniert? Ghet das irgendwie per seriellem Terminal? Leider sind in dem Sketch keine Debug ausgaben vorhanden. Ich brauche also Hilfe von Euch Profis.
Hab noch die Channel-Registrierung auf HEX umgestellt. Keine Ahnung, ob das das Problem löst. Bitte mal updaten, neu starten und neu anlernen.
Die Lib macht von Haus aus jede Menge Debugging. Bitte mal die Ausgaben auf der seriellen Console aufzeichnen. Dann sehen wir vielleicht mehr.
Was mir noch gerade einfällt. BItte mal Prüfen, ob das CC1101 Modul ordentlich funktioniert.
https://asksinpp.de/Grundlagen/FAQ/Fehlerhafte_CC1101.html
Hallo,
ich gehe eigentlich davon aus dass das CC1101 funktioniert. Ich habe damit schon öfters HM devices zusammengebaut. Bisher haben sie auf dem Breadboard immer funktioniert. Aber ich werde das Modul trotzdem noch mal checken.
Ich habe auch Deine geänderten Dateien kopiert, das Device gelöscht und Fhem neu gestartet. Leider bringt das keine Änderung.
Daher hier den Log aus dem Seriellen Monitor.
Nach Arduino Reset:
17:46:16.910 -> AskSin++ V4.1.1 (Nov 17 2019 20:14:06)
17:46:16.945 -> Address Space: 32 - 902
17:46:16.945 -> CC init1
17:46:16.945 -> CC Version: 14
17:46:16.945 -> - ready
17:46:16.945 -> Activate Cycle Msg
17:46:21.090 -> <- 0E 01 A2 10 F33A01 F11111 06 01 00 00 00 - 4170
17:46:21.256 -> -> 0A 01 80 02 F11111 F33A01 00 - 4323
17:46:21.256 -> waitAck: 01
17:46:21.290 -> <- 0E 02 A2 10 F33A01 F11111 06 02 00 00 3C - 4355
17:46:21.425 -> -> 0A 02 80 02 F11111 F33A01 00 - 4517
17:46:21.462 -> waitAck: 01
17:46:21.462 -> <- 0E 03 A2 10 F33A01 F11111 06 03 00 00 3B - 4549
17:46:21.626 -> -> 0A 03 80 02 F11111 F33A01 00 - 4712
17:46:21.626 -> waitAck: 01
17:46:21.660 -> <- 0E 04 A2 10 F33A01 F11111 06 04 00 00 3A - 4744
17:46:21.829 -> -> 0A 04 80 02 F11111 F33A01 00 - 4896
17:46:21.829 -> waitAck: 01
17:46:21.861 -> <- 0E 05 A2 10 F33A01 F11111 06 05 00 00 3B - 4928
17:46:22.029 -> -> 0A 05 80 02 F11111 F33A01 00 - 5101
17:46:22.029 -> waitAck: 01
17:46:22.063 -> <- 0E 06 A2 10 F33A01 F11111 06 06 00 00 3B - 5132
17:46:22.203 -> -> 0A 06 80 02 F11111 F33A01 00 - 5285
17:46:22.203 -> waitAck: 01
17:46:22.234 -> <- 0E 07 A2 10 F33A01 F11111 06 07 00 00 3B - 5316
17:46:22.404 -> -> 0A 07 80 02 F11111 F33A01 00 - 5470
17:46:22.404 -> waitAck: 01
17:46:22.436 -> <- 0E 08 A2 10 F33A01 F11111 06 08 00 00 3B - 5501
17:46:22.570 -> -> 0A 08 80 02 F11111 F33A01 00 - 5654
17:46:22.570 -> waitAck: 01
17:46:22.603 -> <- 0C 09 A2 41 F33A01 F11111 09 00 C8 - 5684
17:46:22.774 -> -> 0A 09 80 02 F11111 F33A01 00 - 5847
17:46:22.774 -> waitAck: 01
17:46:22.806 -> <- 0C 0A A2 41 F33A01 F11111 0A 00 C8 - 5876
17:46:22.942 -> -> 0A 0A 80 02 F11111 F33A01 00 - 6030
17:46:22.942 -> waitAck: 01
17:46:22.976 -> <- 0C 0B A2 41 F33A01 F11111 0B 00 C8 - 6060
17:46:23.144 -> -> 0A 0B 80 02 F11111 F33A01 00 - 6213
17:46:23.144 -> waitAck: 01
17:46:23.177 -> <- 0C 0C A2 41 F33A01 F11111 0C 00 C8 - 6243
17:46:23.313 -> -> 0A 0C 80 02 F11111 F33A01 00 - 6395
17:46:23.313 -> waitAck: 01
17:46:23.346 -> <- 0C 0D A2 41 F33A01 F11111 0D 00 C8 - 6425
17:46:23.849 -> -> 0A 0D 80 02 F11111 F33A01 00 - 6921
17:46:23.849 -> waitAck: 01
17:46:23.884 -> <- 0C 0E A2 41 F33A01 F11111 0E 00 C8 - 6951
17:46:24.020 -> -> 0A 0E 80 02 F11111 F33A01 00 - 7104
17:46:24.020 -> waitAck: 01
17:46:24.054 -> <- 0C 0F A2 41 F33A01 F11111 0F 00 C8 - 7134
17:46:24.222 -> -> 0A 0F 80 02 F11111 F33A01 00 - 7298
17:46:24.222 -> waitAck: 01
17:46:24.256 -> <- 0C 10 A2 41 F33A01 F11111 10 00 C8 - 7327
17:46:24.767 -> -> 0A 10 80 02 F11111 F33A01 00 - 7833
17:46:24.767 -> waitAck: 01
17:46:24.799 -> <- 0E 11 A2 10 F33A01 F11111 06 09 C8 0E 3A - 7865
17:46:24.934 -> -> 0A 11 80 02 F11111 F33A01 00 - 8018
17:46:24.934 -> waitAck: 01
17:46:24.967 -> <- 0E 12 A2 10 F33A01 F11111 06 0A C8 0E 3A - 8049
17:46:25.136 -> -> 0A 12 80 02 F11111 F33A01 00 - 8203
17:46:25.136 -> waitAck: 01
17:46:25.136 -> <- 0E 13 A2 10 F33A01 F11111 06 0B C8 0E 3A - 8235
17:46:25.305 -> -> 0A 13 80 02 F11111 F33A01 00 - 8397
17:46:25.339 -> waitAck: 01
17:46:25.339 -> <- 0E 14 A2 10 F33A01 F11111 06 0C C8 0E 3A - 8429
17:46:25.775 -> -> 0A 14 80 02 F11111 F33A01 00 - 8854
17:46:25.775 -> waitAck: 01
17:46:25.809 -> <- 0E 15 A2 10 F33A01 F11111 06 0D C8 0E 3A - 8885
17:46:25.944 -> -> 0A 15 80 02 F11111 F33A01 00 - 9038
17:46:25.977 -> waitAck: 01
17:46:25.977 -> <- 0E 16 A2 10 F33A01 F11111 06 0E C8 0E 39 - 9069
17:46:26.146 -> -> 0A 16 80 02 F11111 F33A01 00 - 9233
17:46:26.146 -> waitAck: 01
17:46:26.180 -> <- 0E 17 A2 10 F33A01 F11111 06 0F C8 0E 3A - 9264
17:46:26.349 -> -> 0A 17 80 02 F11111 F33A01 00 - 9417
17:46:26.349 -> waitAck: 01
17:46:26.383 -> <- 0E 18 A2 10 F33A01 F11111 06 10 C8 0E 3A - 9449
17:46:26.518 -> -> 0A 18 80 02 F11111 F33A01 00 - 9612
17:46:26.550 -> waitAck: 01
Beim Taster drücken und loslassen:
17:47:18.828 -> <- 0C 1B A2 41 F33A01 F11111 09 01 00 - 27029
17:47:18.995 -> -> 0A 1B 80 02 F11111 F33A01 00 - 27183
17:47:18.995 -> waitAck: 01
17:47:20.846 -> <- 0C 1C A2 41 F33A01 F11111 09 02 C8 - 29030
17:47:20.979 -> -> 0A 1C 80 02 F11111 F33A01 00 - 29182
17:47:21.013 -> waitAck: 01
Beim Versuch über Fhem einen Kontakt zu schließen (Ch01):
17:49:33.347 -> ignore 17 4D 84 70 A5A502 000000 00 E7 2A 80 34 00 86 47 00 00 0A CE 00 00 - 46794
17:49:44.186 -> ignore 0D F8 A2 41 4A13D9 F11111 03 E5 7C 50 - 53354
17:49:44.322 -> ignore 0D F8 80 02 F11111 4A13D9 01 01 7C 00 - 53365
17:49:51.304 -> ignore 17 29 84 70 A5A505 F11111 00 D4 2A 80 2F 00 86 47 00 00 0A 32 00 00 - 53425
17:50:24.856 -> ignore 0E 97 A0 11 F11111 471BF1 02 03 00 00 00 - 53672
17:50:24.990 -> ignore 0E 97 80 02 471BF1 F11111 01 03 00 00 34 - 53683
17:50:26.129 -> ignore 0D F9 A2 41 4A13D9 F11111 03 E6 7A 50 - 53701
17:50:26.297 -> ignore 0D F9 80 02 F11111 4A13D9 01 01 7A 00 - 53711
17:50:26.499 -> ignore 0D 2A 84 10 4484F1 F11111 06 01 40 00 - 53723
17:50:56.331 -> ignore 0D FA A2 41 4A13D9 F11111 03 E7 7A 50 - 53941
17:50:56.498 -> ignore 0D FA 80 02 F11111 4A13D9 01 01 7A 00 - 53951
Da kommt anscheinend nichts an. Was ankommt sind ja nur Signale von anderen HM devicesd wenn ich es richtig interpretiere.
Edit:
Ich habe eben mal den Frequenztest gemacht mit folgendem Ergebnis:
19:19:02.197 -> CC init1
19:19:02.197 -> CC Version: 14
19:19:02.197 -> - ready
19:19:02.197 -> Start searching ...
19:19:02.197 -> Freq 0x21656A 868.300 MHz: 4AD359. 1 / -45dBm
19:19:16.542 -> Search for upper bound
19:19:16.589 -> Freq 0x21657A 868.306 MHz: F11111. 1 / -61dBm
19:19:16.730 -> Freq 0x21658A 868.313 MHz: 4AD359. 1 / -45dBm
19:19:25.513 -> Freq 0x21659A 868.319 MHz: F11111. 1 / -61dBm
19:19:25.661 -> Freq 0x2165AA 868.325 MHz: 4AD359. 1 / -45dBm
19:19:31.005 -> Freq 0x2165BA 868.332 MHz: F11111. 1 / -61dBm
19:19:31.159 -> Freq 0x2165CA 868.338 MHz: F11111. 1 / -62dBm
19:19:42.917 -> Freq 0x2165DA 868.344 MHz: 0
19:20:42.918 -> Search for lower bound
19:20:42.918 -> Freq 0x21655A 868.294 MHz: 4AD359. 1 / -42dBm
19:20:52.278 -> Freq 0x21654A 868.287 MHz: F11111. 1 / -61dBm
19:20:52.419 -> Freq 0x21653A 868.281 MHz: A5A501. 1 / -72dBm
19:20:57.761 -> Freq 0x21652A 868.274 MHz: 4AD359. 1 / -43dBm
19:20:59.073 -> Freq 0x21651A 868.268 MHz: F11111. 1 / -61dBm
19:20:59.214 -> Freq 0x21650A 868.262 MHz: 4AD359. 1 / -44dBm
19:21:05.043 -> Freq 0x2164FA 868.255 MHz: F11111. 1 / -62dBm
19:21:05.184 -> Freq 0x2164EA 868.249 MHz: 4AD359. 1 / -41dBm
19:21:41.119 -> Freq 0x2164DA 868.243 MHz: 0
19:22:41.089 ->
19:22:41.089 -> Done: 0x2164EA - 0x2165CA
19:22:41.089 -> Calculated Freq: 0x21655A 868.294 MHz
19:22:41.089 -> Store into config area: 655A
Edit:
So, noch ein Nachtrag:
Mir is soeben aufgefallen das es prinzipiell funktioniert. Man muss nur lange genug warten.
Folgender Ablauf:
- In Fhem um 20:11:22 auf den Off Button gedrückt.
- Laut seriellen Monitor kommt am Device selbst nichts an.
- lange warten ::)
- Um 20:12:35 wir der Befehl übertragen und schaltet aus.
20:11:21.994 -> ignore 17 44 84 70 A5A500 000000 00 C7 2A 80 36 00 86 47 00 00 0A F1 00 00 - 82016
20:12:04.683 -> ignore 17 5A 84 70 A5A502 000000 00 E1 2A 80 36 00 86 47 00 00 0A CE 00 00 - 82309
20:12:34.682 -> <- 0E 1F A2 10 F33A01 F11111 06 01 C8 00 3C - 82545
20:12:34.817 -> -> 0A 1F 80 02 F11111 F33A01 00 - 82699
20:12:34.817 -> waitAck: 01
20:12:34.922 -> -> 0E 20 A0 11 F11111 F33A01 02 01 00 00 00 - 82805
20:12:35.061 -> <- 0E 20 80 02 F33A01 F11111 01 01 00 00 3A - 82926
20:12:36.028 -> ignore 0D 44 84 10 4484F1 F11111 06 01 3F 00 - 83430
20:13:02.000 -> ignore 17 A7 84 70 A5A503 F11111 00 E2 2A 80 2D 00 86 47 00 00 0A 9A 00 00 - 83609
Das ist ja komisch. Der befehl geht erst nach einer Minute raus. Wie sieht denn der Load am IO aus ? Steht irgendwas im FHEM-Log ? Es muss ja irgendweinen grund geben, warum das so lange dauert.
Hallo,
ich finde es genauso komisch. Ich habe auch mal den HB-UNI-SenAct-4-4 Sketch aufgespielt. Der funktioniert einwandfrei. Aber wieder zurück zum HB-UNI-SenAct-8-8. Anbei ein Log mit Verbose5 vom NanoCUL, Device F33A01 und Ch01.
Es beginnt mit einem Ausschaltvorgang der relativ schnell ging. Das Einschalten danach hat dann wieder sehr lange gedauert.
2019.11.19 08:19:35 5: CUL_HM HM_F33A01 protEvent:CMDs_pending pending:1
2019.11.19 08:19:35 3: CUL_HM set HM_F33A01_Sw_01 off
2019.11.19 08:19:41 5: CUL/RAW: /A0E1BA210F33A01F111110601C8006807
2019.11.19 08:19:41 4: CUL_Parse: nanoCUL_868MHz A 0E 1B A210 F33A01 F11111 0601C8006807 -70.5
2019.11.19 08:19:41 5: nanoCUL_868MHz: dispatch A0E1BA210F33A01F111110601C80068::-70.5:nanoCUL_868MHz
2019.11.19 08:19:41 5: nanoCUL_868MHz sending As0A1B8002F11111F33A0100
2019.11.19 08:19:41 5: CUL F33A01 dly:90ms
2019.11.19 08:19:41 5: SW: As0A1B8002F11111F33A0100
2019.11.19 08:19:41 5: CUL_HM HM_F33A01 protEvent:CMDs_processing... pending:1
2019.11.19 08:19:41 5: CUL_HM HM_F33A01 sent ACK:2
2019.11.19 08:19:41 5: nanoCUL_868MHz sending As0E1CA011F11111F33A010201000000
2019.11.19 08:19:41 5: SW: As0E1CA011F11111F33A010201000000
2019.11.19 08:19:41 5: CUL_HM HM_F33A01 protEvent:CMDs_processing... pending:0
2019.11.19 08:19:41 5: CUL/RAW: /A0E1C8002F33A01F1111101010
2019.11.19 08:19:41 5: CUL/RAW: A0E1C8002F33A01F1111101010/0004705
2019.11.19 08:19:41 4: CUL_Parse: nanoCUL_868MHz A 0E 1C 8002 F33A01 F11111 010100004705 -71.5
2019.11.19 08:19:41 5: nanoCUL_868MHz: dispatch A0E1C8002F33A01F111110101000047::-71.5:nanoCUL_868MHz
2019.11.19 08:19:41 5: CUL_HM HM_F33A01 protEvent:CMDs_done
2019.11.19 08:19:49 5: CUL_HM HM_F33A01 protEvent:CMDs_pending pending:1
2019.11.19 08:19:49 3: CUL_HM set HM_F33A01_Sw_01 on
2019.11.19 08:19:41 4: CUL_Parse: nanoCUL_868MHz A 0E 1B A210 F33A01 F11111 0601C8006807 -70.5
2019.11.19 08:19:41 5: nanoCUL_868MHz: dispatch A0E1BA210F33A01F111110601C80068::-70.5:nanoCUL_868MHz
2019.11.19 08:19:41 5: nanoCUL_868MHz sending As0A1B8002F11111F33A0100
2019.11.19 08:19:41 5: CUL F33A01 dly:90ms
2019.11.19 08:19:41 5: SW: As0A1B8002F11111F33A0100
2019.11.19 08:19:41 5: CUL_HM HM_F33A01 protEvent:CMDs_processing... pending:1
2019.11.19 08:19:41 5: CUL_HM HM_F33A01 sent ACK:2
2019.11.19 08:19:41 5: nanoCUL_868MHz sending As0E1CA011F11111F33A010201000000
2019.11.19 08:19:41 5: SW: As0E1CA011F11111F33A010201000000
2019.11.19 08:19:41 5: CUL_HM HM_F33A01 protEvent:CMDs_processing... pending:0
2019.11.19 08:19:41 5: CUL/RAW: /A0E1C8002F33A01F1111101010
2019.11.19 08:19:41 5: CUL/RAW: A0E1C8002F33A01F1111101010/0004705
2019.11.19 08:19:41 4: CUL_Parse: nanoCUL_868MHz A 0E 1C 8002 F33A01 F11111 010100004705 -71.5
2019.11.19 08:19:41 5: nanoCUL_868MHz: dispatch A0E1C8002F33A01F111110101000047::-71.5:nanoCUL_868MHz
2019.11.19 08:19:41 5: CUL_HM HM_F33A01 protEvent:CMDs_done
2019.11.19 08:19:49 5: CUL_HM HM_F33A01 protEvent:CMDs_pending pending:1
2019.11.19 08:19:49 3: CUL_HM set HM_F33A01_Sw_01 on
2019.11.19 08:22:19 5: CUL/RAW: /A0E1CA210F33A01F1111106010000
2019.11.19 08:22:19 5: CUL/RAW: A0E1CA210F33A01F1111106010000/660C
2019.11.19 08:22:19 4: CUL_Parse: nanoCUL_868MHz A 0E 1C A210 F33A01 F11111 06010000660C -68
2019.11.19 08:22:19 5: nanoCUL_868MHz: dispatch A0E1CA210F33A01F111110601000066::-68:nanoCUL_868MHz
2019.11.19 08:22:19 5: nanoCUL_868MHz sending As0A1C8002F11111F33A0100
2019.11.19 08:22:19 5: CUL F33A01 dly:86ms
2019.11.19 08:22:19 5: SW: As0A1C8002F11111F33A0100
2019.11.19 08:22:19 5: CUL_HM HM_F33A01 protEvent:CMDs_processing... pending:1
2019.11.19 08:22:19 5: CUL_HM HM_F33A01 sent ACK:2
2019.11.19 08:22:19 5: nanoCUL_868MHz sending As0E1DA011F11111F33A010201C80000
2019.11.19 08:22:19 5: SW: As0E1DA011F11111F33A010201C80000
2019.11.19 08:22:19 5: CUL_HM HM_F33A01 protEvent:CMDs_processing... pending:0
2019.11.19 08:22:19 5: CUL/RAW: /A0E1
2019.11.19 08:22:19 5: CUL/RAW: A0E1/D8002F33A01F111110101C800470F
2019.11.19 08:22:19 4: CUL_Parse: nanoCUL_868MHz A 0E 1D 8002 F33A01 F11111 0101C800470F -66.5
2019.11.19 08:22:19 5: nanoCUL_868MHz: dispatch A0E1D8002F33A01F111110101C80047::-66.5:nanoCUL_868MHz
2019.11.19 08:22:19 5: CUL_HM HM_F33A01 protEvent:CMDs_done
Was meinst Du genau mit der Frage wie der Load aussieht? Ich denke mal du meinst den load des Systems, also meinem Raspi. Wie bekomme ich das denn raus?
Edit:
Ich habe jetzt mal den Load des System über eine Android App angeschaut.
CPU geht beim Knopfdrücken von 1% auf max 30%, aber nur sehr kurzzeitig (1-2s)
RAM ist bei 33%
Disk bei ca. 20%
Sollte also alles im grünen Bereich sein.
Edit 20.11.2019:
Ich habe noch mal etwas rumgespielt. die Verzögerung ist nicht konstant. Es dauert mal länger und mal weniger lange. Es wird auch nicht schneller wenn ich das System entlaste und einige funktionen und devices auf disable stelle. Es ist also meiner Meinung nach nicht überlastet. Mir ist noch aufgefallen das der Befehl schneller ausgeführt wird wenn ich am Device den Conifbutton drücke. Auch wenn ich in Fhem mehrfach auf on und off drücke, werden alle Befehle hintereinander ausgeführt sobald ich den Configtaster am device drücke.
Hat hier noch jemand eine Idee was ich ausprobieren könnte um das Problem zu lösen. Oder könnte mal jemand probieren ob es bei ihm auf seinem System läuft?
Danke
Zitat von: FEHMPiDi am 19 November 2019, 08:34:38
Edit 20.11.2019:
Ich habe noch mal etwas rumgespielt. die Verzögerung ist nicht konstant. Es dauert mal länger und mal weniger lange. Es wird auch nicht schneller wenn ich das System entlaste und einige funktionen und devices auf disable stelle. Es ist also meiner Meinung nach nicht überlastet. Mir ist noch aufgefallen das der Befehl schneller ausgeführt wird wenn ich am Device den Conifbutton drücke. Auch wenn ich in Fhem mehrfach auf on und off drücke, werden alle Befehle hintereinander ausgeführt sobald ich den Configtaster am device drücke.
Das was du über die Conifbutton schreibst bringt mich auf die Idee zu fragen ob du
USE_BATTERY_MODE
aktiv hast oder nicht?
Weil im Batt.mode das Device ja im Sleep und nicht im Idle ist (und Burst nicht verwendet wird?)
Nein, use_battery_mode hab ich nicht aktiviert
Ich habe eher die Vermutung dass das Problem irgendwo in FHEM liegt. Es kommt ja laut log per Seriell monitor nichts am Device an. Kann man irgendwie rauskriegen wo fhem hängt. Logfiles habe ich ja hier schon mal hochgeladen. Ich konnte darin aber leider nichts erkennen :(
Wie sieht denn der Sketch aus ? So kann ma da nicht viel sagen.
Hi, den Sketch habe ich von hier: https://github.com/jp112sdl/HB-UNI-SenAct-8-8 (https://github.com/jp112sdl/HB-UNI-SenAct-8-8)
er sieht so aus:
//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++
// 2016-10-31 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
// 2018-11-07 jp112sdl Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
// special thanks to "klassisch" from homematic-forum.de
//- -----------------------------------------------------------------------------------------------------------------------
// define this to read the device id, serial and device type from bootloader section
// #define USE_OTA_BOOTLOADER
#define USE_WOR
#define EI_NOTEXTERNAL
#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <LowPower.h>
#include <actors/PCF8574.h>
#include <Switch.h>
#include <ThreeState.h>
//#define USE_BATTERY_MODE // bei Batteriebetrieb
#define LOWBAT_VOLTAGE 22 // Batterie-Leermeldung bei Unterschreiten der Spannung von U * 10
#define PCF8574_ADDRESS 0x27
#define RELAY_PIN_1 0
#define RELAY_PIN_2 1
#define RELAY_PIN_3 2
#define RELAY_PIN_4 3
#define RELAY_PIN_5 4
#define RELAY_PIN_6 5
#define RELAY_PIN_7 6
#define RELAY_PIN_8 7
#define RELAY_ON_STATE_INVERT true
#define SENS_PIN_1 7
#define SENS_PIN_2 9
#define SENS_PIN_3 5
#define SENS_PIN_4 6
#define SENS_PIN_5 14
#define SENS_PIN_6 15
#define SENS_PIN_7 16
#define SENS_PIN_8 17
#define SABOTAGE_PIN_1 3
#define LED_PIN 4
#define CONFIG_BUTTON_PIN 8
// number of available peers per channel
//#define CREATE_INTERNAL_PEERINGS
#define PEERS_PER_SwitchChannel 3
#define PEERS_PER_SENSCHANNEL 3
#ifdef USE_BATTERY_MODE
#define battOp_ARGUMENT BatterySensor
#define DEV_MODEL 0x3b
#define CYCLETIME seconds2ticks(60UL * 60 * 12 * 0.88) // 60 seconds * 60 (= minutes) * 12 (=hours) * corrective factor
#else
#define battOp_ARGUMENT NoBattery
#define DEV_MODEL 0x3a
#define CYCLETIME seconds2ticks(60UL * 3 * 0.88) // every 3 minutes
#endif
// all library classes are placed in the namespace 'as'
using namespace as;
// define all device properties
const struct DeviceInfo PROGMEM devinfo = {
{0xf3, DEV_MODEL, 0x01},// Device ID
"JPSENACT01", // Device Serial
{0xf3, DEV_MODEL}, // Device Model
0x10, // Firmware Version
as::DeviceType::Switch, // Device Type
{0x01, 0x00} // Info Bytes
};
/**
Configure the used hardware
*/
typedef AvrSPI<10, 11, 12, 13> RadioSPI;
typedef AskSin<StatusLed<LED_PIN>, battOp_ARGUMENT, Radio<RadioSPI, 2> > Hal;
Hal hal;
DEFREGISTER(Reg0, MASTERID_REGS, DREG_INTKEY, DREG_CYCLICINFOMSG, DREG_SABOTAGEMSG)
class SwList0 : public RegList0<Reg0> {
public:
SwList0(uint16_t addr) : RegList0<Reg0>(addr) {}
void defaults() {
clear();
intKeyVisible(true);
sabotageMsg(true);
cycleInfoMsg(true);
}
};
DEFREGISTER(Reg1, CREG_AES_ACTIVE, CREG_MSGFORPOS, CREG_EVENTDELAYTIME, CREG_LEDONTIME, CREG_TRANSMITTRYMAX)
class SensList1 : public RegList1<Reg1> {
public:
SensList1 (uint16_t addr) : RegList1<Reg1>(addr) {}
void defaults () {
clear();
msgForPosA(1);
msgForPosB(2);
aesActive(false);
eventDelaytime(0);
ledOntime(100);
transmitTryMax(6);
}
};
typedef SwitchChannel<Hal, PEERS_PER_SwitchChannel, SwList0, PCF8574Output<PCF8574_ADDRESS>> SwChannel;
typedef ThreeStateChannel<Hal, SwList0, SensList1, DefList4, PEERS_PER_SENSCHANNEL> SensChannel;
class MixDevice : public ChannelDevice<Hal, VirtBaseChannel<Hal, SwList0>, 16, SwList0> {
class CycleInfoAlarm : public Alarm {
MixDevice& dev;
public:
CycleInfoAlarm (MixDevice& d) : Alarm (CYCLETIME), dev(d) {}
virtual ~CycleInfoAlarm () {}
void trigger (AlarmClock& clock) {
set(CYCLETIME);
clock.add(*this);
dev.switchChannel(1).changed(true);
}
} cycle;
public:
VirtChannel<Hal, SwChannel, SwList0> swChannel1, swChannel2, swChannel3, swChannel4, swChannel5, swChannel6, swChannel7, swChannel8;
VirtChannel<Hal, SensChannel, SwList0> sensChannel9, sensChannel10, sensChannel11, sensChannel12, sensChannel13, sensChannel14, sensChannel15, sensChannel16;
public:
typedef ChannelDevice<Hal, VirtBaseChannel<Hal, SwList0>, 16, SwList0> DeviceType;
MixDevice (const DeviceInfo& info, uint16_t addr) : DeviceType(info, addr), cycle(*this) {
DeviceType::registerChannel(swChannel1, 1);
DeviceType::registerChannel(swChannel2, 2);
DeviceType::registerChannel(swChannel3, 3);
DeviceType::registerChannel(swChannel4, 4);
DeviceType::registerChannel(swChannel5, 5);
DeviceType::registerChannel(swChannel6, 6);
DeviceType::registerChannel(swChannel7, 7);
DeviceType::registerChannel(swChannel8, 8);
DeviceType::registerChannel(sensChannel9, 9);
DeviceType::registerChannel(sensChannel10, 10);
DeviceType::registerChannel(sensChannel11, 11);
DeviceType::registerChannel(sensChannel12, 12);
DeviceType::registerChannel(sensChannel13, 13);
DeviceType::registerChannel(sensChannel14, 14);
DeviceType::registerChannel(sensChannel15, 15);
DeviceType::registerChannel(sensChannel16, 16);
}
virtual ~MixDevice () {}
SwChannel& switchChannel (uint8_t num) {
switch (num) {
case 1:
return swChannel1;
break;
case 2:
return swChannel2;
break;
case 3:
return swChannel3;
break;
case 4:
return swChannel4;
break;
case 5:
return swChannel5;
break;
case 6:
return swChannel6;
break;
case 7:
return swChannel7;
break;
case 8:
return swChannel8;
break;
default:
return swChannel1;
}
}
SensChannel& sensorChannel (uint8_t num) {
switch (num) {
case 9:
return sensChannel9;
break;
case 10:
return sensChannel10;
break;
case 11:
return sensChannel11;
break;
case 12:
return sensChannel12;
break;
case 13:
return sensChannel13;
break;
case 14:
return sensChannel14;
break;
case 15:
return sensChannel15;
break;
case 16:
return sensChannel16;
break;
default:
return sensChannel9;
}
}
virtual void configChanged () {
if ( /*this->getSwList0().cycleInfoMsg() ==*/ true ) {
DPRINTLN("Activate Cycle Msg");
sysclock.cancel(cycle);
cycle.set(CYCLETIME);
sysclock.add(cycle);
}
else {
DPRINTLN("Deactivate Cycle Msg");
sysclock.cancel(cycle);
}
}
};
MixDevice sdev(devinfo, 0x20);
ConfigButton<MixDevice> cfgBtn(sdev);
void initPeerings (bool first) {
// create internal peerings - CCU2 needs this
if ( first == true ) {
#ifdef CREATE_INTERNAL_PEERINGS
HMID devid;
sdev.getDeviceID(devid);
for ( uint8_t i = 1; i <= 8; ++i ) {
Peer ipeer(devid, i + 8);
sdev.switchChannel(i).peer(ipeer);
}
for ( uint8_t i = 1; i <= 8; ++i ) {
Peer ipeer(devid, i);
sdev.sensorChannel(i + 8).peer(ipeer);
}
#endif
}
}
void setup () {
DINIT(57600, ASKSIN_PLUS_PLUS_IDENTIFIER);
PCF8574Output<PCF8574_ADDRESS>::init();
bool first = sdev.init(hal);
sdev.switchChannel(1).init(RELAY_PIN_1, RELAY_ON_STATE_INVERT);
sdev.switchChannel(2).init(RELAY_PIN_2, RELAY_ON_STATE_INVERT);
sdev.switchChannel(3).init(RELAY_PIN_3, RELAY_ON_STATE_INVERT);
sdev.switchChannel(4).init(RELAY_PIN_4, RELAY_ON_STATE_INVERT);
sdev.switchChannel(5).init(RELAY_PIN_5, RELAY_ON_STATE_INVERT);
sdev.switchChannel(6).init(RELAY_PIN_6, RELAY_ON_STATE_INVERT);
sdev.switchChannel(7).init(RELAY_PIN_7, RELAY_ON_STATE_INVERT);
sdev.switchChannel(8).init(RELAY_PIN_8, RELAY_ON_STATE_INVERT);
const uint8_t posmap[4] = {Position::State::PosA, Position::State::PosB, Position::State::PosA, Position::State::PosB};
sdev.sensorChannel(9).init(SENS_PIN_1, SENS_PIN_1, SABOTAGE_PIN_1, posmap);
sdev.sensorChannel(10).init(SENS_PIN_2, SENS_PIN_2, SABOTAGE_PIN_1, posmap);
sdev.sensorChannel(11).init(SENS_PIN_3, SENS_PIN_3, SABOTAGE_PIN_1, posmap);
sdev.sensorChannel(12).init(SENS_PIN_4, SENS_PIN_4, SABOTAGE_PIN_1, posmap);
sdev.sensorChannel(13).init(SENS_PIN_5, SENS_PIN_5, SABOTAGE_PIN_1, posmap);
sdev.sensorChannel(14).init(SENS_PIN_6, SENS_PIN_6, SABOTAGE_PIN_1, posmap);
sdev.sensorChannel(15).init(SENS_PIN_7, SENS_PIN_7, SABOTAGE_PIN_1, posmap);
sdev.sensorChannel(16).init(SENS_PIN_8, SENS_PIN_8, SABOTAGE_PIN_1, posmap);
buttonISR(cfgBtn, CONFIG_BUTTON_PIN);
initPeerings(first);
#ifdef USE_BATTERY_MODE
hal.activity.stayAwake(seconds2ticks(15));
hal.battery.low(LOWBAT_VOLTAGE);
// measure battery every 12 hours
hal.battery.init(seconds2ticks(60UL * 60 * 12 * 0.88), sysclock);
#endif
sdev.initDone();
}
void loop() {
bool worked = hal.runready();
bool poll = sdev.pollRadio();
if ( worked == false && poll == false ) {
#ifdef USE_BATTERY_MODE
hal.activity.savePower<Sleep<> >(hal);
#else
hal.activity.savePower<Idle<> >(hal);
#endif
}
}
Danke
Du kannst ja mal versuchen, den PCF8574 rauszunehmen - also die Funktionen leer machen. Dann sehen wir, ob es daran liegt.
Wie meinst du das?
Hardwaremäßig ausbauen, oder den sketch ändern? Wo müsste ich da was rausnehmen im Sketch?
Gruß
Nur in der Software. Mal alle Methoden der Klasse leer machen.
Hallo papa,
kannst Du bitte etwas konkreter werden. Welchen Code soll ich in welcher Klasse löschen?
Ich bin nicht so geübt im Programmieren. Ich kann mir bestehenden code zwar anpassen, aber ich verstehe den Code nicht 100%, noch nicht.
Könntest Du mir bitte die Klasse nennen die ich leeren sollte.
Danke
ich denke mal papa meint es so:
- in HB-UNI-SenAct-8-8-SC wird class PCF8574Output benutzt
- diese ist im file PCF8574.h in ....\libraries\AskSinPP\actors\ implementiert
- dort alle Methoden leer machen, also zB
static void writeWire(uint8_t buffer) {
Wire.beginTransmission(ADDRESS);
Wire.write(buffer);
Wire.endTransmission();
}
ändern in
static void writeWire(uint8_t buffer) {
//Wire.beginTransmission(ADDRESS);
//Wire.write(buffer);
//Wire.endTransmission();
}
Ich zähle dort 8 Methoden zum "Behandeln" ;).
Damit ändert sich nichts direkt im sketch, nur der HW Zugriff auf den PCF8574 wird unterbunden.
Genau - Danke
Danke für die Erklärung. Das habe ich jetzt gemacht. Es ändert sich aber nichts am Verhalten. Ich verstehe auch nicht ganz was das helfen soll. Das Problem ist ja, das aus FHEM das Signal verspätet gesendet wird wenn ich den Kanal über fhem schalte. Es kommt also gar nichts beim Device selber an. Wenn etwas ankommen würde, würde ich das doch im Seriellen Monitor sehen, oder?
Und wenn der Befehl dann aus Fhem raus gesendet wird, funktioniert es ja einwandfrei. Das sehe ich dann auch im seriellen Monitor.
Oder mache ich hier einen Denkfehler?
Hier noch zur Kontrolle wie die PCF8574.h jetzt aussieht:
//- -----------------------------------------------------------------------------------------------------------------------
// AskSin++
// 2018-11-01 papa Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
// 2018-11-01 jp112sdl Creative Commons - http://creativecommons.org/licenses/by-nc-sa/3.0/de/
//- -----------------------------------------------------------------------------------------------------------------------
#ifndef __PCF8574Output_H__
#define __PCF8574Output_H__
#include <Arduino.h>
#include <Wire.h>
namespace as {
struct PCF8574Buffer { uint8_t data, mode; };
template <byte ADDRESS=0x38>
class PCF8574Output {
static PCF8574Buffer& getBuffer();
private:
static void writeWire(uint8_t buffer) {
//Wire.beginTransmission(ADDRESS);
//Wire.write(buffer);
//Wire.endTransmission();
}
public:
inline static void setOutput (uint8_t pin) {
//getBuffer().mode |= bit(pin);
}
inline static void setInput (uint8_t pin) {
//getBuffer().mode &= ~bit(pin);
}
inline static void setHigh (uint8_t pin) {
//getBuffer().data |= bit(pin);
//writeWire((getBuffer().data & getBuffer().mode));
}
inline static void setLow (uint8_t pin) {
//getBuffer().data &= ~bit(pin);
//writeWire((getBuffer().data & getBuffer().mode));
}
inline static uint8_t getState (uint8_t pin) {
//return ((getBuffer().data & bit(pin)) == 0) ? LOW : HIGH;
}
inline static void dump () {
//DPRINT("Address: "); DHEX(ADDRESS);
//DPRINT(" Mode: "); DHEX(getBuffer().mode);
//DPRINT(" Data: "); DHEXLN(getBuffer().data);
}
inline static void init () {
//Wire.begin();
}
};
template<>
inline PCF8574Buffer& PCF8574Output<0x20>::getBuffer () {
static PCF8574Buffer b;
return b;
}
template<>
inline PCF8574Buffer& PCF8574Output<0x21>::getBuffer () {
static PCF8574Buffer b;
return b;
}
template<>
inline PCF8574Buffer& PCF8574Output<0x22>::getBuffer () {
static PCF8574Buffer b;
return b;
}
template<>
inline PCF8574Buffer& PCF8574Output<0x23>::getBuffer () {
static PCF8574Buffer b;
return b;
}
template<>
inline PCF8574Buffer& PCF8574Output<0x24>::getBuffer () {
static PCF8574Buffer b;
return b;
}
template<>
inline PCF8574Buffer& PCF8574Output<0x25>::getBuffer () {
static PCF8574Buffer b;
return b;
}
template<>
inline PCF8574Buffer& PCF8574Output<0x26>::getBuffer () {
static PCF8574Buffer b;
return b;
}
template<>
inline PCF8574Buffer& PCF8574Output<0x27>::getBuffer () {
static PCF8574Buffer b;
return b;
}
template<>
inline PCF8574Buffer& PCF8574Output<0x38>::getBuffer () {
static PCF8574Buffer b;
return b;
}
template<>
inline PCF8574Buffer& PCF8574Output<0x39>::getBuffer () {
static PCF8574Buffer b;
return b;
}
template<>
inline PCF8574Buffer& PCF8574Output<0x3A>::getBuffer () {
static PCF8574Buffer b;
return b;
}
template<>
inline PCF8574Buffer& PCF8574Output<0x3B>::getBuffer () {
static PCF8574Buffer b;
return b;
}
template<>
inline PCF8574Buffer& PCF8574Output<0x3C>::getBuffer () {
static PCF8574Buffer b;
return b;
}
template<>
inline PCF8574Buffer& PCF8574Output<0x3D>::getBuffer () {
static PCF8574Buffer b;
return b;
}
template<>
inline PCF8574Buffer& PCF8574Output<0x3E>::getBuffer () {
static PCF8574Buffer b;
return b;
}
template<>
inline PCF8574Buffer& PCF8574Output<0x3F>::getBuffer () {
static PCF8574Buffer b;
return b;
}
}
#endif
Noch eine allgemeine Frage zum Debug. In der PCF8574.h gibt es ja folgende Zeilen: inline static void dump () {
DPRINT("Address: "); DHEX(ADDRESS);
DPRINT(" Mode: "); DHEX(getBuffer().mode);
DPRINT(" Data: "); DHEXLN(getBuffer().data);
}
Wieso sehe ich die Ausgabe nicht im Seriellen Monitor? Muss man das Debugen noch irgendwo aktivieren?
Hallo,
sorry das ich so hartnäckig bin und so viele und vielleicht auch doofe Fragen stelle. Ich denke aber immer noch das der Fehler eher bei Fhem liegt und nicht beim Sketch des Devices. Warum komme ich auf die Idee? Ich wiederhole mich vielleicht, aber es wird von Fhem kein Befehl an das Device gesendet wenn ich auf den On/Off Button klicke. Das lampensymbol zeigt zwar eine eingeschaltete Lampe, aber mit rotem Ausrufezeichen. Im seriellen Monitor am Device kommt auch keine Message an! Wenn man dann lange genug wartet kommt irgendwann die Message am Device an. Wenn diese ankommt, funktioniert das einschalten auch und das rote Ausrufezeichen in Fhem verschwindet. Ich denke also dass das senden aus Fhem heraus aus irgendeinem Grund verzögert wird. Ein Muster kann ich da aber nicht erkennen. Die Verzögerung ist völlig unregelmäßig. Manchmal geht es recht schnell, meistens dauert es aber sehr lange (einige Minuten). Im Log ist meiner Meinung nach nichts auffälliges zu finden. Den hatte ich hier auch schon mal gepostet. Da es ja ein neues Device für Fhem ist und das anscheinend noch niemand mit Fhem benutzt hat, hier noch eine Frage zum Code in der HMConfig_AskSinPPCustom den papa mir auf die Schnelle erstellt hat. Evtl. ist hier ja noch ein Bug drin?
$HMConfig::culHmModel{"F33A"} = {name=>"HB-UNI-SenAct-8-8-SC",st=>'custom',cyc=>'',rxt=>'c:l',lst=>'1,3:1p.2p.3p.4p.5p.6p.7p.8p,4:9p.10p.11p.12p.13p.14p.15p.16p',chn=>"Sw:1:8,Sen:9:16"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-8-8-SC00"}{fwUpdate} = "<filename>";
$HMConfig::culHmChanSets{"HB-UNI-SenAct-8-8-SC01"} = $HMConfig::culHmSubTypeSets{"switch"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-8-8-SC02"} = $HMConfig::culHmSubTypeSets{"switch"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-8-8-SC03"} = $HMConfig::culHmSubTypeSets{"switch"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-8-8-SC04"} = $HMConfig::culHmSubTypeSets{"switch"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-8-8-SC05"} = $HMConfig::culHmSubTypeSets{"switch"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-8-8-SC06"} = $HMConfig::culHmSubTypeSets{"switch"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-8-8-SC07"} = $HMConfig::culHmSubTypeSets{"switch"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-8-8-SC08"} = $HMConfig::culHmSubTypeSets{"switch"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-8-8-SC09"} = $HMConfig::culHmSubTypeSets{"THSensor"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-8-8-SC10"} = $HMConfig::culHmSubTypeSets{"THSensor"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-8-8-SC11"} = $HMConfig::culHmSubTypeSets{"THSensor"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-8-8-SC12"} = $HMConfig::culHmSubTypeSets{"THSensor"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-8-8-SC13"} = $HMConfig::culHmSubTypeSets{"THSensor"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-8-8-SC14"} = $HMConfig::culHmSubTypeSets{"THSensor"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-8-8-SC15"} = $HMConfig::culHmSubTypeSets{"THSensor"};
$HMConfig::culHmChanSets{"HB-UNI-SenAct-8-8-SC16"} = $HMConfig::culHmSubTypeSets{"THSensor"};
$HMConfig::culHmRegModel{"HB-UNI-SenAct-8-8-SC"} = { intKeyVisib=>1, cyclicInfoMsg=>1, sabotageMsg=>1 };
$HMConfig::culHmRegChan {"HB-UNI-SenAct-8-8-SC01"} = $HMConfig::culHmRegType{switch};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-8-8-SC02"} = $HMConfig::culHmRegType{switch};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-8-8-SC03"} = $HMConfig::culHmRegType{switch};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-8-8-SC04"} = $HMConfig::culHmRegType{switch};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-8-8-SC05"} = $HMConfig::culHmRegType{switch};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-8-8-SC06"} = $HMConfig::culHmRegType{switch};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-8-8-SC07"} = $HMConfig::culHmRegType{switch};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-8-8-SC08"} = $HMConfig::culHmRegType{switch};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-8-8-SC09"} = $HMConfig::culHmRegType{threeStateSensor};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-8-8-SC10"} = $HMConfig::culHmRegType{threeStateSensor};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-8-8-SC11"} = $HMConfig::culHmRegType{threeStateSensor};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-8-8-SC12"} = $HMConfig::culHmRegType{threeStateSensor};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-8-8-SC13"} = $HMConfig::culHmRegType{threeStateSensor};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-8-8-SC14"} = $HMConfig::culHmRegType{threeStateSensor};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-8-8-SC15"} = $HMConfig::culHmRegType{threeStateSensor};
$HMConfig::culHmRegChan {"HB-UNI-SenAct-8-8-SC16"} = $HMConfig::culHmRegType{threeStateSensor};
$customMsg{"HB-UNI-SenAct-8-8-SC"} = sub {
my ($msg,$target) = @_;
my $channel = $msg->channel;
return $msg->processThreeState($target) if $channel > 8;
return $msg->processSwitchStatus($target) if $msg->isStatus;
return ();
};
Generell die Frage. Was passiert denn in Fhem überhaupt wenn ich auf den On/Off Button drücke. Woher weiß fhem welches SIgnal es senden muss? Steht das in der HMMsg.pm? Ist da evtl. noch ein Bug?
Danke für Eure Hilfe