Hallo, habe ein VCCU konfiguriert, welche aber nicht funktioniert.
Habe zwei CUL's eingebunden, von den einer nun auf ,,opened" gegangen ist.
Eigentlich sollte doch nun alles über den zweiten weiter laufen, aber alle HM-Geräte gehen auf MISSING-ACK.
List:
Internals:
DEF F10000
IODev nanoCUL
LASTInputDev nanoCUL2
MSGCNT 2
NAME VCCU
NOTIFYDEV global
NR 191
NTFY_ORDER 50-VCCU
STATE nanoCUL:opened,nanoCUL2:ok,
TYPE CUL_HM
assignedIOs nanoCUL,nanoCUL2
channel_01 Rauchmelder_Team
channel_02 VCCU_Btn2
channel_03 VCCU_Btn3
channel_04 VCCU_Btn4
nanoCUL2_MSGCNT 2
nanoCUL2_RAWMSG A13A286704DC24C00000001501E00F0C0303A6EE6::-83.5:nanoCUL2
nanoCUL2_RSSI -83.5
nanoCUL2_TIME 2018-07-27 15:36:52
READINGS:
2018-07-27 15:32:18 state nanoCUL:opened,nanoCUL2:ok,
2018-07-27 14:51:46 unknown_206334 received
2018-07-27 15:00:23 unknown_378031 received
2018-07-27 10:32:22 unknown_454DEA received
2018-07-27 15:36:52 unknown_4DC24C received
2018-07-27 15:10:29 unknown_502B86 received
2018-07-27 13:20:39 unknown_AA8B0B received
helper:
HM_CMDNR 53
mId FFF0
regLst ,0
rxType 1
expert:
def 1
det 0
raw 1
tpl 0
io:
prefIO
vccu VCCU
ioList:
nanoCUL
nanoCUL2
mRssi:
mNo
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
dev 1
vrt 1
Attributes:
IODev nanoCUL
IOList nanoCUL,nanoCUL2
IOgrp VCCU
expert 2_raw
group CUL
hmKey. xxxxxxxxxxx
icon cul
model CCU-FHEM
subType virtual
webCmd virtual:update
Beide CUL's haben die hmid F10000
Könnt ihr mir bitte helfen?
Gruß
Thomas
Hier das LIST von einem Rolladen:
Internals:
DEF 505381
IODev nanoCUL
NAME HM_505381
NOTIFYDEV global
NR 206
NTFY_ORDER 50-HM_505381
STATE MISSING ACK
TYPE CUL_HM
protCmdDel 2
protResnd 6 last_at:2018-07-27 15:51:56
protResndFail 2 last_at:2018-07-27 15:52:02
protSnd 2 last_at:2018-07-27 15:51:42
protState CMDs_done_Errors:1
Helper:
DBLOG:
level:
DBLOG:
TIME 1532699502.40301
VALUE set_15
READINGS:
2018-07-26 21:47:08 CommandAccepted yes
2017-01-08 12:15:10 D-firmware 2.8
2017-01-08 12:15:10 D-serialNr NEQ1365038
2017-06-26 23:37:17 PairedTo 0xF10000
2017-01-08 12:15:15 R-driveDown 50 s
2017-01-08 12:15:15 R-driveTurn 0.5 s
2017-01-08 12:15:15 R-driveUp 50 s
2017-01-08 12:15:14 R-pairCentral 0xF10000
2017-03-04 18:43:40 R-powerUpAction off
2017-01-08 12:15:15 R-sign off
2017-06-26 23:37:16 RegL_00. 02:01 0A:F1 0B:00 0C:00 15:FF 18:00 00:00
2017-06-26 23:37:17 RegL_01. 08:00 09:00 0A:00 0B:01 0C:F4 0D:01 0E:F4 0F:05 10:00 30:06 57:24 56:00 00:00
2018-07-26 21:47:15 deviceMsg off (to VCCU)
2018-07-27 15:51:42 level set_15
2018-07-26 21:47:15 motor stop:off
2018-07-26 21:47:15 pct 0
2018-06-05 07:32:16 powerOn 2018-06-05 07:32:16
2018-07-26 21:47:15 recentStateType info
2017-01-10 07:30:00 sabotageAttackId_ErrIoId_F10000 cnt:2
2018-07-27 15:52:02 state MISSING ACK
2018-07-26 21:47:15 timedOn off
helper:
HM_CMDNR 207
cSnd 11F10000505381020124,11F1000050538102011E
dlvlCmd ++A011F1000050538102011E
mId 006A
regLst ,0,1,3p
rxType 1
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +505381,00,01,00
prefIO
rxt 0
vccu VCCU
p:
505381
00
01
00
mRssi:
mNo
io:
nanoCUL:
nanoCUL2:
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat 00
role:
chn 1
dev 1
prs 1
Attributes:
IODev VCCU
IOgrp VCCU
alias RolladenStraße
autoReadReg 4_reqStatus
devStateIcon on:fts_shutter_10 off:fts_shutter_90
expert 2_raw
firmware 2.8
group Schaltungen/Aktoren
icon fts_shutter_updown
model HM-LC-Bl1PBU-FM
peerIDs 00000000,
room 52_Geo
serialNr NEQ1365038
subType blindActuator
webCmd statusRequest:toggleDir:on:off:up:down:stop
Hallo Thomas,
sieht auf den ersten Blick ok aus.
Haben die HM Geräte denn IOgrp gesetzt?
Edit: Du hast ergänzt, aber IODev darf nicht auf VCCU stehen!
Gruß Otto
Ich habe nun IODev aus den Attributen gelöscht, bekomme aber immernoch MISSING ACK
Naja gelöscht ist auch falsch, das wird eigentlich automatisch gesetzt (ich weiß nicht wie man das erzwingen kann) also trag mal probehalber einen CUL ein.
Der arme Kerl weiß ja sonst nicht wie er senden soll. ;D
Das klingt nicht lustig. Aber wenn es mal in Teilen funktioniert hat, ist es evtl. noch was anderes, das opened ist auch seltsam (keine Kommunikation mit dem ATMega).
Wo stecken die Geräte, wie sind sie definiert? Alles direkt an USB? Ist da sonst noch was?
Ansonsten:
Kommt denn was rein, wenn du am Aktor eine Taste drückst?
Eigentlich sollte irgendein RSSI-Wert da stehen, hier ist aber gar nichts zu sehen...
Alle paar Wochen geht einer der beiden nanoCUL's auf opened und ich muss diesen ausstecken und nach dem einstecken und reopen geht er meist wieder. Einer hängt an einem aktiven HUB und der andere an einem RJ45-USB-Konverter damit ich drei Stockwerke versorgen kann.
KA warum das so ist aber das ist ein anderes Thema.
Ich bin gerade im Urlaub und kann nur per VPN tätig sein.
Das Tool usbreset funzt nicht und dummerweise geht die VCCU auch nicht wie sie soll.
Wenn ich IOgrp lösche und IODev auf nanoCUL2 setze, funzt der Aktor.
Also muss doch mit der VCCU etwas nicht ok sein.
Zitat von: thgorjup am 27 Juli 2018, 16:12:11Alle paar Wochen geht einer der beiden nanoCUL's auf opened und ich muss diesen ausstecken und nach dem einstecken und reopen geht er meist wieder. Einer hängt an einem aktiven HUB und der andere an einem RJ45-USB-Konverter damit ich drei Stockwerke versorgen kann.
KA warum das so ist aber das ist ein anderes Thema.
Ich bin gerade im Urlaub und kann nur per VPN tätig sein.
Das Tool usbreset funzt nicht und dummerweise geht die VCCU auch nicht wie sie soll.
Auch wenn es OT ist: Löten könnte helfen, klingt nach dem Test-PIN-Problem (fhem-wiki zu arduino). Wenn es das ist, bekommst du diesen Arduino nur wieder ans Laufen, wenn du ihn stromlos machst (oder sonst wer) .
Zitat von: thgorjup am 27 Juli 2018, 16:17:34
Wenn ich IOgrp lösche und IODev auf nanoCUL2 setze, funzt der Aktor.
Also muss doch mit der VCCU etwas nicht ok sein.
Und wenn Du (wie es sein soll) IOgrp auf VCCU lässt und initial IODev auf nanoCUL2 setzt?
ok, der eine von dreien funzt weiterhin. Aber die anderen beiden nicht.
Aber ich denke nicht, dass die zu weit entfernt sind.
naja aber primär verwaltet die VCCU in dem Fall nur den IO - Du kannst jederzeit eingreifen.
Was die VCCU mit einem opened macht weiß ich nicht - ich habe keine CULs.
Lösch doch noch deinen HmKey aus deinem List, den muss je nicht jeder wissen :)
Der Unterschied ist, dass die beiden, welche nicht funktionieren unter Internals bei IODev nen nanoCUL (opened) stehen haben. Der funktionierende hat den nanoCUL2 in den Internals.
Mach mal den opened CUL zu.
EDIT: Mist, das geht mit einem CUL nicht...
Zitat von: thgorjup am 27 Juli 2018, 16:12:11
Ich bin gerade im Urlaub und kann nur per VPN tätig sein.
Das Tool usbreset funzt nicht und dummerweise geht die VCCU auch nicht wie sie soll.
Kurze Zwischenfrage, du hast aber nicht aus dem Urlaub heraus mal schnell auf VCCU per VPN umgestellt, oder?
Zitat von: thgorjup am 27 Juli 2018, 16:38:11
Der Unterschied ist, dass die beiden, welche nicht funktionieren unter Internals bei IODev nen nanoCUL (opened) stehen haben. Der funktionierende hat den nanoCUL2 in den Internals.
Und im attr IODev?
Funzt:
Internals IODev: nanoCUL2
Attributes IODev: nanoCUL2
Funzt nicht:
Internals IODev: nanoCUL
Attributes IODev: nanoCUL2
Muss bei Internals nicht IODev = VCCU stehen?
@Amenophis86
Ich hab VCCU schon lange aber jetzt merke ich erst, dass es nicht funzt wie es soll.
Zitat von: thgorjup am 27 Juli 2018, 17:19:06
Ich hab VCCU schon lange aber jetzt merke ich erst, dass es nicht funzt wie es soll.
M.E. ist das nicht ganz richtig:
1. Du wußtest schon länger, dass die CULs ein Problem haben ;) .
2. Die VCCU verwaltet den weggehängten CUL weiter, weil er auf "opened" steht. Leider kann man kein close oder so darauf ausführen (geht bei anderen IO's). Vermutlich kann die VCCU einfach nicht feststellen, dass der ATMega hinter dem USB-Seriell-Wandler nicht mehr erreichbar ist und verwendet ihn daher auch ganz regulär weiter.
Tippen würde ich darauf, dass alles wie erwartet funktioniert, wenn der opened CL weg/ausdrücklich nicht zu erreichen ist. Leider gibt es bei den CUL-Geräten kein close, disconnect oder so - vielleicht geht attr dummy.
Oder eben mal das preferred IO bei allen CUL_HM-Geräten umstellen.
EDIT:Also sowas wie
attr TYPE=CUL_HM IOgrp VCCU:nanoCUL2
ok, ich probiere mal den preferred CUL bei einem Gerät ändern.
Ich möchte den nanoCUL nicht löschen, denn ich weiß nicht was das für Auswirkungen hat.
EDIT: Das Umsellen des Prefered hat geklappt 👍
Dann habe ich DEF des nanoCUL geändert, dass er auf disconnected geht und sieht da, die Rolläden funktionieren! Danke für eure Hilfe.
Zitat von: thgorjup am 27 Juli 2018, 17:19:06
Muss bei Internals nicht IODev = VCCU stehen?
Nein IODev ist immer wirklich das IO Gerät
Zitat von: thgorjup am 27 Juli 2018, 17:30:15
EDIT: Das Umsellen des Prefered hat geklappt 👍
Dann habe ich DEF des nanoCUL geändert, dass er auf disconnected geht und sieht da, die Rolläden funktionieren! Danke für eure Hilfe.
Schön!
Denkst du an das [gelöst] und bei deiner Rückkehr dann an den Lötkolben für den TestPIN ;) ?
Joh, mach ich
FYI, zurück aus dem Urlaub und Test-Pin mit GND verbunden. Der nanoCUL funktioniert weiterhin. Mal paar Wochen beobachten ob "opened" wieder passiert.....
Zu früh gefreut, heute nach 9 Tagen ist einer der nanoCUL's wieder auf "opened" gegangen.
Hatte wohl doch nichts mir dem TEST-Pin Problem zutun. Ich habe jetzt kein "reopen", etc. probiert, weil ich dazu keine Zeit hatte. Also nur schnell aus- und wieder eingesteckt.
Gibt es einen Thread in dem das Problem ausgiebig behandelt wird?