Bezüglich VCCU verunsichert

Begonnen von jove01, 06 März 2015, 02:44:21

Vorheriges Thema - Nächstes Thema

martinp876

hm - ich finde die Einleitung nicht schlecht. Eine vccu ist nicht notwendig, daher stellt sich Usern m.E. die frage ob und warum man eine einrichten sollte.

Schade, dass du nicht alles selbst machen kannst.

Prof. Dr. Peter Henning

Hallo Martin,

die Aussage "Eine VCCU ist nicht notwendig" ist vollkommen korrekt. Sie steht aber für den unvoreingenommenen Leser in klarem Widerspruch zu dem Satz "Eine vccu sollte immer angelegt werden."

Kaum ein Paar von Sätzen könnte meine Aussage zu dem Artikel besser untermalen. Dass diese begriffliche Unklarheit sich auch an anderer Stelle im Artikel findet, wird m.E. auch durch die zahlreichen Rückfragen belegt. 

Ich bin übrigens nicht der Meinung, dass Sachen nur gut werden, wenn ich sie mache. Oder prinzipiell schlecht sind, wenn sie von anderen gemacht werden. Also lästere _bitte_ diesmal nicht.

LG

pah




martinp876

das ist kein Läster  - jedenfalls nicht meinerseits.
die Sätze stehe auch nicht im Widerspruch. Die VCCU ist nicht notwendig, sollte aber angelegt werden. Somit ist es eine Empfehlung - was hier sehr deutlich gemacht werden soll. Ich zumindest verstehe es genau so - Imperativ, Konjunktiv.
Wäre das System "korrekt" gebaut wäre einen VCCU Pflicht - würde automatisch angelegt. Stand jetzt ist, dass sie optional ist, man das System ohne betreiben kann, es aber nicht (von mir) empfohlen wird.

Ich hatte auch mit dem Gedanken gespielt, die vccu automatisch zu erstellen und zu verlinken. Einige Funktionen die in HMInfo realisiert sind wären hier anzubringen - auch z.B. ActionDetector.
Wenn ich das nun automatisiere - und die vccu zur Pflicht mache - wären einige User .... zumindest überrascht.
Wäre der 2. Satz also Pflicht wäre er nicht notwendig, da ich eine vccu einfach anlegen würde - Punkt. Der erste dann auch nicht.

Zusammenfassend: evtl. sollte ich eine vccu automatisch anlegen, wenn ich ein IO finde, das in HM genutzt wird. Dann wäre die Einleitung im Wiki nicht notwendig. Würde dem alt-User aber ein paar gewohnte Vorgehensweisen verweigern.

ujaudio

ZitatWürde dem alt-User aber ein paar gewohnte Vorgehensweisen verweigern.

Da ich nun eine vccu angelegt habe, würde mich interessieren, was an altgewohnten Vorgehensweisen mir nun verweigert wird? Mak sehen, was ich selbst feststellen werde...

Einen lieben Gruß
Jürgen
Einen lieben Gruß
Jürgen

martinp876

Prinzipiell wäre ein top-down vorgehen sinnvoll. Man legt eine vccu an und legt IOs an. dann verlinkt man die vccu mit IOs.
Attribut IODev geht den User nichts mehr an.
die HMId des IO und dessen Konfig (homematic mode) kann der User nicht mehr ändern
Devices müssen einer vccu zugewiesen werden um senden zu können - da die vccu die IOs verwalten.

Somit kommt es zu Problemen bei bestehenden Installationen... insofern, das ich Attribute automatisch setzen und ignorieren würde. Im speziellen eben IODev und IOgrp. Zuweisungen des User, welches IODev er gewählt hat wären hinfällig, wenn es nicht über IOgrp eingestellt ist. Ich könnte/würde versuchen die Konfig zu übernehmen... ändert aber die Gewohnheiten.

Ausserdem hätten die User eine vccu neu, falls nicht schon vorhanden. Änderungen der HMId im IO sind damit nicht mehr erlaubt (so lange es der VCCU zugewiesen ist).

ein aus meiner sicht gut organisiertes System würde so arbeiten - mehr automatisch, weniger optionen.

harry66

Hallo Martin,

ich habe mir gerade mal das Wiki und diese Diskussion durchgelesen.
Und ich muss pah recht geben weder das Wiki noch deine Aussagen hier sind für mich wirklich verständlich :-\

Den letzten Beitrag habe ich mindestens 5x gelesen.

Ich versuche mal das ganze so zusammen zu fassen wie ich die VCCU verstanden habe, bitte korrigieren falls ich falsch liege  ;D

1. vccu verwaltet Homematic IO's
2. sollte benutzt werden (spätestens wenn mehr als 1x IO)

Welchen Vorteil eine VCCU bei 1x IO hat habe ich noch nicht verstanden :-[

Gruß Rolf

BananaPI, RPI, nanoCUL433, RCS 1000 N Comfort, Dect200, Powerline546E, MAX!Cube, 7xMAX! HT's,3xMAX!FK HMLAN, HM-LC-Bl1PBU-FM, HM-LC-Sw4-Ba-PCB Relay Karte,  LW12, Sqeezelite, TabletUI=Kindel 8" FireHD+Handy,AmazonEcho

martinp876

abfangen und melden von Ereignissen die CUL_HM zugeordnet sind.
Zitatvccu verwaltet Homematic IO's
sowie nicht zugeordnete Ereignisse im Bereich der IOs

Zitatsollte benutzt werden (spätestens wenn mehr als 1x IO)
sollte immer benutzt werden

was ist am ersten Satz nicht verständlich? "immer" ist bold. "Sollte" ist eine Empfehlung, es ist und bleibt ein soll.
Alles Andere sind weitergehende Hinweise.

Aber: warum wird hier darüber diskutiert, dass man es ändern sollte. Warum schreibt es einer nicht einfach besser? Ist so üblich. Befasse dich damit, mache es richtig.

martinp876

ich habe den Eintrag etwas überarbeitet. Nicht viel.
Inhaltlich ist immer noch alles korrekt. Es sind nicht alle Readings erwähnt, wie das Empfangen von Nachrichten unbekannter Devices.
Der erste Satz sollte die klare Empfehlung nun ein-eindeutig darstellen, wenn auch nicht begründen.

frank

#23
Zitat von: martinp876 am 30 Mai 2015, 08:31:02
Ich hatte auch mit dem Gedanken gespielt, die vccu automatisch zu erstellen und zu verlinken. Einige Funktionen die in HMInfo realisiert sind wären hier anzubringen - auch z.B. ActionDetector.
Wenn ich das nun automatisiere - und die vccu zur Pflicht mache - wären einige User .... zumindest überrascht.
ich behaupte mal, dass mehr user überrascht sind, wenn sie keine vccu haben und "help me"-einträge im log finden:

2015.03.01 12:56:14 3: CUL_0: Unknown code A0F9B8610319C3F0000000A24880F0040::-106.5:CUL_0, help me!

oder hminfo entsprechende fehlermeldungen wirft. oder eben "verunsichert" und/oder über eine entscheidung zur nutzung der vccu "unschlüssig/überfordert" sind. insgesamt wahrscheinlich weniger trubel mit automatischer definition.

einfach mal ein datum setzen für zb weihnachten 2015, und eine nichtnutzung als "deprecatet" bezeichnen.

ZitatPrinzipiell wäre ein top-down vorgehen sinnvoll. Man legt eine vccu an und legt IOs an. dann verlinkt man die vccu mit IOs.
Attribut IODev geht den User nichts mehr an.
die HMId des IO und dessen Konfig (homematic mode) kann der User nicht mehr ändern
bei cul-nutzung müsste man aber beachten, dass einige/viele die cul hauptsächlich im homematic-modus nutzen und zum schalten von zb intertechno kurzzeitig den modus/frequenz wechseln.
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

martinp876

Zitateinfach mal ein datum setzen für zb weihnachten 2015, und eine nichtnutzung als "deprecatet" bezeichnen.
könnte man. Eine automatische Erstellung der VCCU könnte ich einbauen...

Zitatbei cul-nutzung müsste man aber beachten, dass einige/viele die cul hauptsächlich im homematic-modus nutzen und zum schalten von zb intertechno kurzzeitig den modus/frequenz wechseln.
00_CUL macht Rudi. Ich blockiere hier demnach nichts. Das Vorgehen ist natürlich ein Problem. Schaltet der User den mode um und die vccu will über dieses Device senden klappt es nicht. Der User sollte also das Device aus der vccu Liste nehmen - in jeden Fall. Damit hat er alle Rechte - und kein HM-IO mehr. Das könnte er auch mit HMLAN (man kann es nur nicht umschalten).

justme1968

das umschalten in den it modus ist glaube ich kein problem. das passiert transparent und automatisch nur für die sende dauer eines kommandos. danach wird direkt wieder zurück geschaltet. die hm seite bekommt davon nichts mit und es behindert auch die vccu nicht wirklich.

das es fast immer sinnvoller ist für jedes protokoll ein eigenes io zu haben ist natürlich unabhängig davon trotzdem richtig.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

ujaudio

Noch ein konkretes Thema:

Meine vccu hat gibt  mir folgende Infos:
DEF  2CC699
IODev  hmusb
NAME  xx_Zentrale
NR  163
STATE  hmusb:ok
TYPE  CUL_HM
assignedIOs  hmusb
channel_01  xx_Zentrale_Btn1


Die letzte Zeile zerbreitet mir Kopfzerbrechen, weil ich immer wieder mal eine Meldung bekomme "define xx_Zentrale_Btn1 first" - und ich weiß nicht, was ich definieren soll.

Das gab es übrigens anfangs gar nicht, sondern ist erst durch "herumspielen, in der Hoffnung meine Sprachausgabe hinzubekommen, entstanden. Zumindest hatte ich es anangs nicht bemerkt und auch keine Fehlermeldungen.
Einen lieben Gruß
Jürgen

martinp876

da bin ich jetzt auch ziemlich ratlos. Es gibt im Code nur eine Meldung mit define...first

"please define a device with hmId:".$devHmId." first"
was sich auf ein Device bezieht welches fehlt. Wenn man einen Kanal definieren will es aber kein Device dazu gibt wird dies verweigert. Kann es sein, dass die gepostete Meldung nicht  nicht korrekt wiedergegeben ist? Wär schade - macht arbeit.


ujaudio

Hallo Martin,

die Meldung ist absolut  richtig wiedergegeben. Aber sie kommt möglicherweise nicht von der vccu!? Ich glaube mittlerweile sogar, dass es gar nichts mit der vccu zu tun hat --> hatte. Ich habe mal die vccu komplett entfernt, FHEM neu gestartet und dann die vccu wieder neu definiert. Seitdem tritt die Meldung nicht mehr auf.

Gruß
Jürgen
Einen lieben Gruß
Jürgen

Deudi

Zitat von: ujaudio am 30 Mai 2015, 22:30:12
Die letzte Zeile zerbreitet mir Kopfzerbrechen, weil ich immer wieder mal eine Meldung bekomme "define xx_Zentrale_Btn1 first" - und ich weiß nicht, was ich definieren soll.

Das gab es übrigens anfangs gar nicht, sondern ist erst durch herumspielen...

Bist du vielleicht mal in der Weboberfläche bei deiner vccu an den Slider gekommen (set vccu virtual 1)?
Ich finde den etwas unglücklich, da man so recht schnell channels definieren kann, die nicht jeder braucht.
Gigabyte Brix, Ubuntu 16.04.3 LTS, Homematic, Z-Wave, EnOcean, Shelly@MQTT, SIGNALduino, JeeLink DAVIS-Sketch