[gelöst] VCCU nachträglich einrichten

Begonnen von no_Legend, 08 Dezember 2015, 11:52:24

Vorheriges Thema - Nächstes Thema

no_Legend

Hallo Leute,

mometan läuft mein FHEm ohne VCCU.
Ich habe 2 HMLAN im Einsatz.
An der Haustür habe ich auch eine HM-Sec-Key mit AES im Einsatz.

Nun bin ich auf den Beitrag im Wiki gestoßen. http://www.fhemwiki.de/wiki/Virtueller_Controller_VCCU

Ist es Sinvoll immer eine VCCU einzurichen?
Muss ich auf was achten, damit keine Probleme mit dem bereits bestehenden Setup bekomme?

Danke und Gruß Robert
Docker FHEM immer aktuell,4x HMLAN, CUL443, CUL868 -homekit/siri -tablet ui -homebridge
Device, diverse:
Homematic, Shelly, Tasmota, MQTT, Unifi Network usw.

marvin78

Es ist immer sinnvoll eine VCCU einzurichten. Die Gründe dafür stehen ja schon in dem von dir verlinkten Wiki-Artikel. Wenn du dich bei der Einrichtung an den Artikel hälst, sollte es keine Probleme geben. Auch ich habe die VCCU nachträglich eingerichtet (da es sie noch gar nicht gab, als ich angefangen habe).

Jetzt habe ich so viel geschrieben und sehe dann, dass die Antwort auf all deine Fragen in einem einzigen Satz im von dir verlinkten Artikel steht:

ZitatDer Einsatz einer VCCU ist immer sinnvoll und sollte auch nur bei der Nutzung eines einzelnen IO Devices in FHEM angelegt sein. Es entstehen keine Nachteile.

no_Legend

Ich hab den Artikel auch gelesen.

Kann aber sein, dass jemand schon probleme gehabt hat und mir diese mitteilen will, dass ich diese gleich umschiffen kann.

Dann werde ich nachher diese mal einbauen.

Ich meld mich dann nochmal, hab bestimmt noch ein paar fragen.
Docker FHEM immer aktuell,4x HMLAN, CUL443, CUL868 -homekit/siri -tablet ui -homebridge
Device, diverse:
Homematic, Shelly, Tasmota, MQTT, Unifi Network usw.

frank

ZitatKann aber sein, dass jemand schon probleme gehabt hat
allerdings.  :)  eine suche nach vccu wird dich erschlagen.
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

marvin78

Zitat von: frank am 08 Dezember 2015, 12:07:00
allerdings.  :)  eine suche nach vccu wird dich erschlagen.

War dabei auch etwas, was tatsächlich nicht auf unsachgemäße Bedienung oder nicht Lesen wollen zurück zu führen war?

no_Legend

Um es in den Worten meines damaligen Meisters zu sagen:
"Wer lesen kann ist klar im Vorteil"
Docker FHEM immer aktuell,4x HMLAN, CUL443, CUL868 -homekit/siri -tablet ui -homebridge
Device, diverse:
Homematic, Shelly, Tasmota, MQTT, Unifi Network usw.

frank

ZitatWar dabei auch etwas, was tatsächlich nicht auf unsachgemäße Bedienung oder nicht Lesen wollen zurück zu führen war?
eigentlich nicht.

es scheint wohl eher eine tief verwurzelte und unbegründete angst vor einer vccu zu existieren, die zu teils sonderbaren anwendungsfehlern führt. ähnlich dem menschlichen verhalten gegenüber spinnen.  :o
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

no_Legend

Hab es jetzt mal definiert.
Scheint bisher zu gehen, testen kann ich erst wenn ich Zuhause bin.

Eine Frage habe ich aber:
Wenn ich dien die Config rein gehen um Manuell zu bearbeiten bekomme ich imemr folgenden Fehler:
VCCU1: unknown IODev specified

Die VCCU hab ich wie folgt angelegt, bisher habe ich nur einem Handsender die VCCU als IOgrp VCCU1 zugeweisen.


define VCCU1 CUL_HM XXXXX
attr VCCU1 IODev HMLAN1
attr VCCU1 IOList HMLAN1,HMLAN2
attr VCCU1 expert 2_full
attr VCCU1 model CCU-FHEM
attr VCCU1 room 9.80_Sender
attr VCCU1 subType virtual
attr VCCU1 webCmd virtual:update
Docker FHEM immer aktuell,4x HMLAN, CUL443, CUL868 -homekit/siri -tablet ui -homebridge
Device, diverse:
Homematic, Shelly, Tasmota, MQTT, Unifi Network usw.

marvin78

Packe die Definition in der Config mal hinter die Definitionen der HMLANs. Hat sie die gleiche HMID wie beide HMLANs?

no_Legend

Zitat von: marvin78 am 08 Dezember 2015, 12:54:50
Packe die Definition in der Config mal hinter die Definitionen der HMLANs. Hat sie die gleiche HMID wie beide HMLANs?

;)
Du scheinst deine Pappenheimer schon richtig gut zu kennen.
Hab dei VCCU hinter die HMLANS gepackt, und der fehler ist weg.

Die HMID ist bei allen drei die gleiche.
Hab gelesen dass man es so  machen soll?
Oder hab ich wieder mal nicht richtig gelesen?
Docker FHEM immer aktuell,4x HMLAN, CUL443, CUL868 -homekit/siri -tablet ui -homebridge
Device, diverse:
Homematic, Shelly, Tasmota, MQTT, Unifi Network usw.

marvin78

Doch. Das ist richtig. Wollte mich nur vergewissern ;)

no_Legend

Zitat von: marvin78 am 08 Dezember 2015, 13:12:10
Doch. Das ist richtig. Wollte mich nur vergewissern ;)

Dank dir für deinen super Support.  :D

Ich schließ das Thema dann.
Docker FHEM immer aktuell,4x HMLAN, CUL443, CUL868 -homekit/siri -tablet ui -homebridge
Device, diverse:
Homematic, Shelly, Tasmota, MQTT, Unifi Network usw.

no_Legend

Hi,

ich wärme hier jetzt doch noch mal kurz auf.

Was passiert eigentlich mit dem Attribut IODev, wenn man IOgrp setzt?
Sollte man das Attr. löschen?

Gruß Robert
Docker FHEM immer aktuell,4x HMLAN, CUL443, CUL868 -homekit/siri -tablet ui -homebridge
Device, diverse:
Homematic, Shelly, Tasmota, MQTT, Unifi Network usw.

martinp876

Es wird automatisch gesetzt. Löschen nutzt nichts. Der kernal braucht es, daher kann ich es nicht verschwinden lassen.
Faktisch ist es ein infernal und zeigt den letzten io send an.

no_Legend


Zitat von: martinp876 am 13 Dezember 2015, 15:18:56
Es wird automatisch gesetzt. Löschen nutzt nichts. Der kernal braucht es, daher kann ich es nicht verschwinden lassen.
Faktisch ist es ein infernal und zeigt den letzten io send an.

Okay Martin alles klar.
Gehe ich richtig in der Annahme das die iogrp bevorzugt wird?
Docker FHEM immer aktuell,4x HMLAN, CUL443, CUL868 -homekit/siri -tablet ui -homebridge
Device, diverse:
Homematic, Shelly, Tasmota, MQTT, Unifi Network usw.