HM-Sen-MDIR-O-2 - trigDst_F11034 noConfig

[mimue]

Ich habe Heute einen HM-Sen-MDIR-O-2 in Betrieb genommen, unter Readings finde ich

Code Auswählen Erweitern

trigDst_F11034 noConfig 2014-09-15 17:01:24

HMinfo sagt dazu:

Code Auswählen Erweitern

configCheck done:
trigger sent to undefined device
triggerUndefined: BewegungsMelderUGVorraum:F11034

F11034 ist die die HMid (D-HMIdAssigned) des LAN_HomeMatic an dem ich das Gerät angemeldet habe.

Die Trigger-Destination sollte doch wohl eher ein Gerät enthalten, das vom Sensor direkt geschaltet wird ?

Was entgeht mir hier ? Oder ist das normal ?

mimue

[martinp876]

definiere eine vccu mit der HMId des HMLAN.
CUL_HM kennt die ID des HMLAN nicht, das ist ein anderes Modul. mit der vccu (u.a.) regelst du dies

[mimue]

Mit der vccu (u.a.) regelst du dies

Danke für die Auskunft, martinp876,

der HMinfo scheint jetzt zufrieden zu sein, zumindest sagt er jetzt nur noch

Code Auswählen Erweitern

configCheck done: wenn ich configCheck abrufe.

Allerdings sagt der HM-Sen-MDIR-O-2 immer noch

Code Auswählen Erweitern

trigDst_F11034 noConfig, obwohl ich ihn nur am HMLAN "angelernt", aber keinen Aktor als Peer zugewiesen habe.

Ich hätte erwartet, daß 

Code Auswählen Erweitern

trigDst erst durch Zuweisung eines Peer ( also etwa um einen Lichtschalter direkt zu schalten, wenn etwas vorbeiläuft ) einen Wert erhält.

Oder muß ich den Sensor jetzt am VCCU neu "anlernen" ?

mimue

Nachtrag: Jetzt zeigt der Sensor noch

Code Auswählen Erweitern

trigDst_VirtualCCU  noConfig

[martinp876]

der Trigger wird bei diesen Aktoren zur Zentrale geschickt - on gepeert oder nicht. Daher der Eintrag.
Er wird von HMInfo nicht als Fehler gewertet, ist nur eine Info.

[mimue]

... ist nur eine Info.

So weit so gut, was möchte mir diese Info mitteilen ? Respektive, was könnte ich mit VCCU und meinen Devices besser regeln als ohne ?
Ich habe mal versucht den Thread zu VCCU zu lesen und zu verstehen, allerdings habe ich zu wenig Hintergrund zu CCU & Co um damit ernsthaften Schaden anrichten zu können. Der WIKI Eintrag dazu ist auch nicht gerade erhellend, schade eigentlich.

Bis vor ein paar Tagen wußte ich noch nichts von HmInfo und VCCU, alles lief wie ich es wollte. Mit HmInfo und VCCU tut es das auch, außer das ich jetzt das Gefühl habe irgendetwas wesentliches zu übersehen.

mimue

[martinp876]

ccu ist die control-unit - so die HM bezeichnung für ihre HW. Diese steuert die Devices, eigentlich was FHEM macht.
eine HM-ccu hat eine ID und kann mehrere IO-devices nutzen - alle mit der gleichen ID. Nicht das IO sondern die CCU ist der Endpunkt der Verarbeitung. In FHEM - HM-sektion war dies nicht so. die IOs sind/waren in der HM-Zentrale (CUL_HM) nicht wirklich bekannt - oder nicht sauber eingetragen. Das führt zu einigen komplikationen.

eine vccu ist nun eine HM-entity, die in CUL_HM dargestellt werden kann, entsprechende Readings hat und ios kontrollieren kann. Prinzipiell würde ich immer eine vccu vorschreiben, da nur so ein korrektes System-abbild erzeugt werden kann. Der Betrieb ohne vccu ist immer noch möglich und wird auch nicht abgeschaltet.

Man kann mehrere vccu's einrichten, wenn man will.
Eine vccu
- kontrolliert ein oder mehrere IOs
- hat bis zu 50 virtuelle Kanäle, erlaubt das entsprechende peeren
- kann IOs ersatzschalten, wenn eines ausfällt
- stellt trigger und readings dar, für jeden ihrer Kanäle
- erlaubt die Nutzung entsprechender kommandos wie press

eigentlich das, was auch HM mit seiner CCU kann - nur die Ersatzschaltung ist flexiber. Und du kannst mehrere vccus.

[mimue]

Danke für die ausführliche Antwort.

Eine vccu ist nun eine HM-entity, die in CUL_HM dargestellt werden kann, entsprechende Readings hat und ios kontrollieren kann. Prinzipiell würde ich immer eine vccu vorschreiben, da nur so ein korrektes System-abbild erzeugt werden kann. Der Betrieb ohne vccu ist immer noch möglich und wird auch nicht abgeschaltet.

Wenn ich die Vorteile der VCCU nutzen möchte, muß ich dann alle HM-Geräte vom HMLAN abmelden und an der VCCU neu anlernen ?

mimue

[marvin78]

Nein. Das ist nicht nötig. Der Übergang ist reibungslos. Die VCCU ist, wie das V sagt, ja nur ein virtuellles Device.

[mimue]

Der Übergang ist reibungslos.

Danke für den Hinweis, allerdings ist der "Übergang" bei mir wohl eher reibungsbehaftet.

Ich habe gerade mal mit einem Gerät getestet: Abmelden vom HLAN (factory reset) und

Code Auswählen Erweitern

set VirtualCCU hmPairForSec 60 abgesetzt. Der Versuch den HM-LC-SW4-SM mit der vccu zu paaren schlug fehl. Falls das so nicht vorgesehen ist, wäre es vielleicht sinnvoll an dieser Stelle

Code Auswählen Erweitern

hmPairForSec erst gar nicht anzubieten ?

Na, jedenfalls wieder mit HMLAN gepaart, das hat die vccu auch nicht zur Kenntnis genommen.

Code Auswählen Erweitern

get VirtualVCC listDevice liefert weiterhin  nichts

Wie mache ich also Geräte mit der vccu bekannt ?

mimue

[marvin78]

Ich habe doch geschrieben, dass du NICHT neu anlernen musst.

Du musst nur deine HM-IO-Devices in das Attribut IOList der VCCU eintragen (siehe commandref). Der Rest geht von selbst. Du kannst dann in den jeweiligen Devices noch ein bevorzugtes IO-Device definieren (Attribut IOgrp), musst das aber nicht. Steht mehrfach hier im Forum. Suche einfach mal nach "vccu" oder ähnlichem.

Und das neu anlernen über die VCCU funktioniert bei mir mit neuen Geräten übrigens hervoragend (aktuelle Version von FHEM).

[mimue]

Ich habe doch geschrieben, dass du NICHT neu anlernen musst.

Ruhig Blut ! Das habe ich parallel gemacht, bevor ich Deine Antwort gelesen hatte

Du musst nur deine HM-IO-Devices in das Attribut IOList der VCCU eintragen (siehe commandref).

In der aktuellen commandref.html / commandref_DE.html kommt das Stichwort IOList nicht vor. Ein Gerät vccu steht auch nicht in der Geräte-Liste, es wird lediglich unter CUL_HM, parameter IOgrp eher beiläufug erwähnt.

Steht mehrfach hier im Forum. Suche einfach mal nach "vccu" oder ähnlichem.

Danke!

Und das neu anlernen über die VCCU funktioniert bei mir mit neuen Geräten übrigens hervoragend (aktuelle Version von FHEM).

Das bezweifle ich.

mimue

[martinp876]

pairen kann man ein device an eine HMId. Das ist (war ) die ID des IO-devices. Wenn du nun eine vccu einrichtest, bekommt die die ID, welche das IO device schon vorher hatte

attr HMLAN1 HMId 123456
=>
define vccu CUL_HM 123456

wenn du das so machst, muss nichts gepairt werde, da das Device nicht den geringsten Unterschied sehen kann.

Solltest du eine neue HMId nutzen, musst du neu pairen - und zwar alless, was du mit dieser vccu steuern willst. Zu gebachten ist dann, dass manche gepairten devices sich nicht von einer andren Zentrale pairen lassen, die lassen sich nur etwas von der eingetragenen Zentrale sagen. Das ist nun einmal so.

Du kannst diese Devices reseten, dann sind sie nicht gepairt und bereit für neues pairing.
Alternativ kannst du das Register pairedTo in allen devices ändern, so lange du noch die alte ID nutzt

set <dev> regSet pairedTo 654321
...
attr HMLAN HMId 654321

so grob das Prinzip. Besser/einfacher ist sicher, die ID einfach zu belassen

[marvin78]

Das bezweifle ich.

Lach. Das kannst du gerne tun, das ändert aber nichts. Ich sag nur "Kaum macht man's richtig, schon geht's". Wie Martin schon sagt, lernt man nichts an den HMLAN oder die VCCU an, sondern an die HMID. FHEM hilft dir nur dabei. Und wie es richtig geht, steht mehrfach hier um Forum. Und nein, ich suche es nicht für dich raus...

[mimue]

...so grob das Prinzip. Besser/einfacher ist sicher, die ID einfach zu belassen

Danke für die ausführliche Erklärung.

mimue

[mimue]

set <dev> regSet pairedTo 654321

also das geht bei mir nicht, da bekomme ich bei jedem Gerät

Code Auswählen Erweitern

pairedTo failed: supported register are confBtnTime intKeyVisib lgActionType lgCtDlyOff lgCtDlyOn lgCtOff lgCtOn lgCtValHi lgCtValLo lgMultiExec lgOffDly lgOffTime lgOffTimeMode lgOnDly lgOnTime lgOnTimeMode lgSwJtDlyOff lgSwJtDlyOn lgSwJtOff lgSwJtOn localResDis pairCentral powerUpAction shActionType shCtDlyOff shCtDlyOn shCtOff shCtOn shCtValHi shCtValLo shOffDly shOffTime shOffTimeMode shOnDly shOnTime shOnTimeMode shSwJtDlyOff shSwJtDlyOn shSwJtOff shSwJtOn sign statusInfoMinDly statusInfoRandom transmitTryMax

Auch das aaren eines Gerätes direkt mit der virtuellen CCU klappt bei mir nicht, ich habe das an einer jungfräulichen Installation mit zwei CUL_HM und einem HMLAN probiert. Es muß in jedem Fall zuerst mit einem Transceiver gepaart werden, die virtuelle CCU nimmt das Gerät erst zur Kenntnis wenn anschließend im Gerät

Code Auswählen Erweitern

attr <Name> IOgrp VirtualCCU gestzt wird.

mimue