Fehlermeldung "HMLAN1 does not support CUL_HM" IOList VCCU

Begonnen von dancatt, 08 September 2021, 10:24:03

Vorheriges Thema - Nächstes Thema

frank

dein anwendungsfall wurde wohl einfach nicht bedacht.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

khk123

Hmmm, hab eigentlich, wie im Wiki beschrieben ganz normal die VCCU definiert.
FHEM6.2, RasPi4, RasPi Zero W,
CUL V3, HM, ZWave, IT, vcontrol, owntracks, alexa

frank

du hast alles richtig gemacht.

ich war schon immer dafür, dass cul_hm automatisch eine vccu anlegt, wenn keine existiert.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

khk123

Das wäre sicherlich der beste Weg.

Viele Grüße und nochmals danke für die Hilfe.
Karlheinz
FHEM6.2, RasPi4, RasPi Zero W,
CUL V3, HM, ZWave, IT, vcontrol, owntracks, alexa

frank

mit den aktuellen patches von https://forum.fhem.de/index.php/topic,123436.0.html habe ich jedenfalls keine probleme beim anlegen einer 2. vccu das attribut IOList über das frontend zu setzen.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Beta-User

Zitat von: frank am 17 Oktober 2021, 12:06:57
mit den aktuellen patches von https://forum.fhem.de/index.php/topic,123436.0.html habe ich jedenfalls keine probleme beim anlegen einer 2. vccu das attribut IOList über das frontend zu setzen.
Auch mit nur einer bzw. der ersten VCCU ist das IOList-Attribut grundsätzlich setzbar. "Problematisch" ist  "nur noch", wenn man das IO erst nach der VCCU definiert und NICHT für CUL_HM vorbereitet wird (indem man rfmode setzt).

Aber "einfach so" den rfmode zu ändern, sollte man m.e. nicht automatisch machen!

(VCCU automatisch anlegen wäre m.E. überlegenswert, aber dann wissen die User vermutlich genausowenig wie beim ACTIONDETECTOR, was das soll...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files