Hi, ich habe seit gestern 16:55 ein Problem, dass fhem keinen Rollladen, keinen Lichtschalter mehr steuern kann.
Ich vermutete erst ein fehlerhaften HM-MOD-RPI-PCB und habe diesen getauscht, den neuen habe ich auf FW 1.4.1 geupdated aber dieser scheint auch nicht senden zu wollen.
Empfang scheint zu klappen, wenn ich den DEVCNT unt CNT richtig interpretiere.
EventMon:
2021-01-22 14:58:40 CUL_HM AuffahrtLicht commState: CMDs_pending
2021-01-22 14:58:40 CUL_HM AuffahrtLicht set_off noArg
2021-01-22 14:58:40 CUL_HM AuffahrtLicht commState: CMDs_processing...
2021-01-22 14:58:58 CUL_HM AuffahrtLicht ResndFail
2021-01-22 14:58:58 CUL_HM AuffahrtLicht commState: CMDs_done_Errors:1
2021-01-22 14:58:58 CUL_HM AuffahrtLicht MISSING ACK
HMUART1:
AssignedPeerCnt 15
CNT 217
Clients :CUL_HM:
DEF /dev/ttyAMA0
DEVCNT 217
DevState 99
DevType UART
DeviceName /dev/ttyAMA0@115200
FD 4
FUUID 5d9ca77e-f33f-969e-1143-a85feabeb1bf5686
LastOpen 1611323405.50591
NAME HMUART1
NOTIFYDEV global
NR 21
NTFY_ORDER 50-HMUART1
PARTIAL
RAWMSG 040219
STATE opened
TYPE HMUARTLGW
XmitOpen 1
model HM-MOD-UART
msgLoadCurrent 13
msgLoadHistory 0/4/9/-/-/-/-/-/-/-/-/-
msgLoadHistoryAbs 13/13/9/0/-/-/-/-/-/-/-/-/-
owner 58405F
owner_CCU VCCU
Readings
D-HMIdAssigned 58405F 2021-01-22 14:50:07
D-HMIdOriginal 58405F 2021-01-22 14:50:08
D-firmware 1.4.1 2021-01-22 14:50:08
D-serialNr OEQ0307349 2021-01-22 14:50:08
D-type HM-MOD-UART 2021-01-22 14:49:58
cond ok 2021-01-22 14:50:08
load 13 2021-01-22 15:00:08
loadLvl low 2021-01-22 14:50:08
state opened 2021-01-22 14:50:05
Danke für Eure Hilfe im Voraus!
Schalte ich einen Rollladen manuell über den Schalter ist das Ergebnis im fhem zu sehen.
Internals
DEF 6B8ACB
FUUID 5d9ca782-f33f-969e-b415-5b952619e6064a27
HMUART1_MSGCNT 18
HMUART1_RAWMSG 0500002F03A4106B8ACB139AF20601C800
HMUART1_RSSI -47
HMUART1_TIME 2021-01-22 15:30:43
IODev HMUART1
LASTInputDev HMUART1
MSGCNT 18
NAME HM_6B8ACB
NOTIFYDEV global
NR 59
NTFY_ORDER 50-HM_6B8ACB
STATE oben
TYPE CUL_HM
chanNo 01
lastMsg No:03 - t:10 s:6B8ACB d:139AF2 0601C800
protCmdDel 6
protLastRcv 2021-01-22 15:30:14
protRcv 8 last_at:2021-01-22 15:30:14
protResnd 9 last_at:2021-01-22 15:26:17
protResndFail 3 last_at:2021-01-22 15:26:21
protSnd 3 last_at:2021-01-22 15:26:02
protState CMDs_done_Errors:1
rssi_at_HMUART1
cnt:18 min:-48 max:-42 avg:-45.77 lst:-47
Readings
PairedTo 0x139AF2
das passt nicht mehr, die HM-MOD-RPI-PCB hat jetzt die 58405F oder ist das die VCCU?
Ich komme mal von einer HM-LAN installation, dann migriert zu VCCU mit HM-MOD-RPI-PCB. Das lief jetzt Jahre lang stabil bis gestern. Der RPI hatte nicht rebootet und es wurden keine Änderungen gemacht.
WTF! Wie von Geisterhand geht es plötzlich wieder.
Ich werde das alte Funkmodul mal untersuchen und schauen, es der Grund für den ersten Ausfall war.
Das der 2te HMMODRPIPCB nicht sofort funktionierte mit anderer ID mag ein anderes Problem gewesen sein.
Hat Jemand ein paar Tipps für mich?
Hallo Elo,
Ich würde Dich bitten Codetags zu verwenden: https://forum.fhem.de/index.php/topic,71806.0.html
So wie ich deine Auszüge interpretiere, hast Du den neuen IO nicht der VCCU untergeordnet. Der hat die falsche hmId.
Poste am besten mal ein je ein list der VCCU und der beiden IOs.
Gruß Otto
Hallo Otto, sorry für die vergessenen Codetags, ich war irgendwie total nervös als sich nichts mehr steuern lassen wollte.
Hier die Listings:
VCCU:
Internals:
DEF 139AF2
FUUID 5d9ca782-f33f-969e-c2a8-7993757b8b2eb086
IODev HMUART1
NAME VCCU
NOTIFYDEV global
NR 32
NTFY_ORDER 50-VCCU
STATE HMUART1:ok
TYPE CUL_HM
assignedIOs HMUART1
channel_01 VCCU_Btn1
READINGS:
2017-08-16 07:52:03 CommandAccepted yes
2021-01-23 03:01:18 IOopen 1
2021-01-23 03:01:18 state HMUART1:ok
2018-03-09 10:15:35 unknown_00E803 received
2017-04-09 16:00:19 unknown_37C0D5 received
2017-08-15 11:36:56 unknown_39B77E received
2017-04-04 15:15:42 unknown_42013D received
2017-04-11 02:20:43 unknown_439374 received
2017-08-12 18:40:16 unknown_4730E3 received
2017-04-07 05:51:33 unknown_4AD2AE received
2017-04-13 11:13:21 unknown_4AD2B3 received
2017-03-27 07:32:27 unknown_4AD2BE received
2017-04-16 22:55:36 unknown_4AD2C4 received
2017-04-17 07:40:00 unknown_4AD2D9 received
2017-04-24 15:11:29 unknown_4DABD7 received
2017-08-15 12:55:25 unknown_4DAC2B received
2017-08-16 01:46:35 unknown_5176C0 received
2018-11-13 20:23:05 unknown_5277AC received
2019-02-18 10:00:08 unknown_58405F received
2018-11-17 10:29:19 unknown_680E42 received
2019-06-19 17:43:36 unknown_6B8ACB received
2019-11-12 07:56:53 unknown_6C2521 received
2017-08-15 09:46:22 unknown_7A6F84 received
2017-08-16 07:51:50 unknown_8135A0 received
2017-08-15 21:20:25 unknown_8CC739 received
2017-08-15 16:17:08 unknown_8DF307 received
2017-01-21 12:00:56 unknown_8DFF54 received
2017-01-17 15:47:56 unknown_A02728 received
2017-08-15 21:59:09 unknown_A49288 received
2017-04-26 09:14:43 unknown_A6B5E3 received
2017-08-16 06:30:00 unknown_B42D28 received
2017-08-09 08:30:00 unknown_B94B9A received
2017-08-15 19:06:51 unknown_BF1104 received
helper:
HM_CMDNR 88
mId FFF0
peerFriend peerSens,peerAct
peerOpt -:virtual
regLst
rxType 1
ack:
cmds:
TmplKey :no:1611367276.02296
TmplTs 1611367276.02296
cmdKey 0:1:1::VCCU::01:
cmdLst:
assignHmKey noArg
assignIO -IO- [({set}|unset)]
clear [(readings|rssi|msgErrors|{msgErrors}|unknownDev)]
defIgnUnknown noArg
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getDevInfo noArg
hmPairForSec [-sec-]
hmPairSerial -serial-
peerSmart -peerOpt-
raw -data- [...]
reset noArg
tplSet_0 -tplChan-
unpair noArg
update noArg
virtual [(1..50;1|{1})]
lst:
condition slider,0,1,255
peer
peerOpt AuffahrtLicht,BadRoll,CUL_HM_HM_LC_Dim1TPBU_FM_1A6375_Sw1_V_01,CUL_HM_HM_LC_Dim1TPBU_FM_1A6375_Sw1_V_02,CUL_HM_HM_RC_8_2F5265_Btn_01,CUL_HM_HM_RC_8_2F5265_Btn_02,CUL_HM_HM_RC_8_2F5265_Btn_03,CUL_HM_HM_RC_8_2F5265_Btn_04,CUL_HM_HM_RC_8_2F5265_Btn_05,CUL_HM_HM_RC_8_2F5265_Btn_06,CUL_HM_HM_RC_8_2F5265_Btn_07,CUL_HM_HM_RC_8_2F5265_Btn_08,EsszimmerRoll,GaestezRollRechts,HM_418B2D_WindowRec,HM_418B2D_remote,HM_4419A1_WindowRec,HM_4419A1_remote,HM_441A56_WindowRec,HM_441A56_remote,HM_6B8ACB,HM_6C2521_WindowRec,HM_6C2521_remote,KuecheRoll,KuecheSchalter_Btn_01,KuecheSchalter_Btn_02,TuerTerasseRoll,WohnzDimmCouch_Dim_V_01,WohnzDimmCouch_Dim_V_02,WohnzDimmCouch_Sw,WohnzDimmTisch_Sw,WohnzRollLinks,WohnzRollRechts
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
listDevice noArg
param -param-
expert:
def 1
det 0
raw 0
tpl 0
io:
prefIO
vccu VCCU
ioList:
HMUART1
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
tmpl:
Attributes:
IODev HMUART1
IOList HMUART1
IOgrp VCCU
alias VCCU
model CCU-FHEM
room Wohnzimmer
subType virtual
webCmd virtual:update
HMUART1:
Internals:
AssignedPeerCnt 15
CNT 61
Clients :CUL_HM:
DEF /dev/ttyAMA0
DEVCNT 61
DevState 99
DevType UART
DeviceName /dev/ttyAMA0@115200
FD 4
FUUID 5d9ca77e-f33f-969e-1143-a85feabeb1bf5686
LastOpen 1611367276.36155
NAME HMUART1
NOTIFYDEV global
NR 21
NTFY_ORDER 50-HMUART1
PARTIAL
RAWMSG 040200
RSSI -67
STATE opened
TYPE HMUARTLGW
XmitOpen 1
model HM-MOD-UART
msgLoadCurrent 0
msgLoadHistory 0/0/0/0/0/0/0/0/0/0/0/0
msgLoadHistoryAbs 0/0/0/0/0/0/0/0/0/0/0/0/0
owner 139AF2
owner_CCU VCCU
Helper:
CreditTimer 4310
FW 66561
Initialized 1
SendCnt 31
AckPending:
LastSendLen:
3
3
Log:
IDs:
PendingCMD:
RoundTrip:
Delay 0.00278115272521973
loadLvl:
lastHistory 1611431778.86769
MatchList:
1:CUL_HM ^A......................
Peers:
193FD7 +193FD7,00,00,00
1941A0 +1941A0,00,00,00
1A6375 +1A6375,00,00,00
1A7254 +1A7254,00,00,00
1AF952 +1AF952,00,00,00
1BCB4E +1BCB4E,00,00,00
1BCD6F +1BCD6F,00,00,00
1BCEBC +1BCEBC,00,00,00
2AAF9B +2AAF9B,00,00,00
418B2D +418B2D,00,00,00
4419A1 +4419A1,00,00,00
441A56 +441A56,00,00,00
680E42 +680E42,00,00,00
6B8ACB +6B8ACB,00,00,00
6C2521 +6C2521,00,00,00
READINGS:
2021-01-23 03:01:18 D-HMIdAssigned 139AF2
2021-01-23 03:01:18 D-HMIdOriginal 58405F
2021-01-23 03:01:18 D-firmware 1.4.1
2021-01-23 03:01:18 D-serialNr OEQ0307349
2021-01-23 03:01:09 D-type HM-MOD-UART
2021-01-23 03:01:18 cond ok
2021-01-23 18:55:10 load 0
2021-01-23 03:01:18 loadLvl low
2021-01-23 03:01:16 state opened
helper:
Attributes:
alias HMUART1
hmId 139AF2
icon cul_868
room Wohnzimmer
Wie gesagt, gestartet bin ich mal mit einem HMLAN an dem wurde alle gepairt, dann bin ich irgendwann nach Jahren auf den HMMODRPI+VCCU umgestiegen.
Meine größte Sorge war, dass ich alle Geräte neu anlernen muss, das wäre schade, da viele Sensoren unter Tapeten liegen.
Dann das merkwürdige Verhalten vor 2 Tagen. Das 2te HMMODRPI ist nicht angeschlossen, dafür brauche ich 1-2 Tage, Zeitmangel mit Kindern und so.
Was ist eigentlich aus dem hmKey geworden, den der HMLAN noch hatte?
Aber jetzt sieht das gut aus?
In deinem ersten Post hatte mich das irritiert:
D-HMIdAssigned 58405F 2021-01-22 14:50:07
D-HMIdOriginal 58405F 2021-01-22 14:50:08
Das war in der Tat ich, es ließ sich halt noch nichts steuern nur empfangen und ich hatte das Gefühl es müssten evtl. beide Werte gleich sein.
Das hatte ich dann wieder rückgängig gemacht, als sich keine Besserung eingestellt hatte. Dann ging nach einem Reboot und ein paar Minuten wieder alles.
Soweit mir bekannt, darf fas 800Mhz Band nicht übermäßig von einer Installation oder einem Device genutzt werden, wewegen es da eine Zeitslotlösung gibt.
Das kann ich aber bei mir ausschließen, außer ein Device ist 'verrückt' geworden, danach habe ich aber nicht gesucht.
Die alte Antenne HMMODRPI muss ich noch mal in einem neu aufgesetzten Pi auf Herz und Nieren testen...
Gibt es hier User, denen das HMMODRPI mal kaputt gegangen ist im Betrieb?
Können Externe meine Anlage außer betrieb nehmen durch vollspammen das 800Mhz Bereiches?