Ich habe Heute einen HM-Sen-MDIR-O-2 in Betrieb genommen, unter Readings finde ich
trigDst_F11034 noConfig 2014-09-15 17:01:24
HMinfo sagt dazu:
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
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
Zitat von: martinp876 am 16 September 2014, 20:37:23
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
configCheck done: wenn ich configCheck abrufe.
Allerdings sagt der HM-Sen-MDIR-O-2 immer noch
trigDst_F11034 noConfig, obwohl ich ihn nur am HMLAN "angelernt", aber keinen Aktor als Peer zugewiesen habe.
Ich hätte erwartet, daß
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
trigDst_VirtualCCU noConfig
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.
Zitat von: martinp876 am 18 September 2014, 19:51:39
... 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
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.
Danke für die ausführliche Antwort.
Zitat von: martinp876 am 19 September 2014, 20:45:24
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
Nein. Das ist nicht nötig. Der Übergang ist reibungslos. Die VCCU ist, wie das V sagt, ja nur ein virtuellles Device.
Zitat von: marvin78 am 20 September 2014, 08:48:28
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
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
hmPairForSec erst gar nicht anzubieten ?
Na, jedenfalls wieder mit HMLAN gepaart, das hat die vccu auch nicht zur Kenntnis genommen.
get VirtualVCC listDevice liefert weiterhin nichts
Wie mache ich also Geräte mit der vccu bekannt ?
mimue
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).
Zitat von: marvin78 am 20 September 2014, 09:24:11
Ich habe doch geschrieben, dass du NICHT neu anlernen musst.
Ruhig Blut ! Das habe ich parallel gemacht, bevor ich Deine Antwort gelesen hatte :-)
Zitat von: marvin78 am 20 September 2014, 09:24:11Du 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.
Zitat von: marvin78 am 20 September 2014, 09:24:11Steht mehrfach hier im Forum. Suche einfach mal nach "vccu" oder ähnlichem.
Danke!
Zitat von: marvin78 am 20 September 2014, 09:24:11Und das neu anlernen über die VCCU funktioniert bei mir mit neuen Geräten übrigens hervoragend (aktuelle Version von FHEM).
Das bezweifle ich.
mimue
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
Zitat von: mimue am 20 September 2014, 16:57:55
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...
Zitat von: martinp876 am 20 September 2014, 18:51:41
...so grob das Prinzip. Besser/einfacher ist sicher, die ID einfach zu belassen
Danke für die ausführliche Erklärung.
mimue
Zitat von: martinp876 am 20 September 2014, 18:51:41
set <dev> regSet pairedTo 654321
also das geht bei mir nicht, da bekomme ich bei jedem Gerät
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
attr <Name> IOgrp VirtualCCU gestzt wird.
mimue
sorry, register ist pairCentral
mache das nächste mal ein
get <entity> regList
Hallo
ich würde mich hier gern einhängen da ich das gleiche Problem habe.
Ich wollte gern 2 Bewegungsmelder nicht direkt an einen Aktor koppeln sonder über notify einbinden um sie später
tageszeitabhängig andere Ereignisse schalten zu können.
Jedoch bekomme auch immer im Eventlog eine Meldung "trigDst_F11034 noConfig"
Einbinden wollte ich so
define Bewegung notify CUL CUL_HM_HM_Sen_MDIR_O_2_2B0364:motion set STECK_02 on-for-timer 10
oder ähnlich.
Eine VCCU ist für mich noch absolutes Neuland und derzeit ein Buch mit vielen Siegeln.
Ich hatte eine angelegt bekomme jedoch dann die Meldung " trigDst_myVCCU: noConfig"
Vielleicht kann auch mal jemand ein Stück seiner funktionierenden fhem.cfg einstellen damit man sich orientieren kann.
Danke.
Hat die vccu die id f11034 ? Sicher eine cul. Ist der mdir mit dieser id gepeert ?
Und umgekehrt ?
Hallo
die vccu hat die ID F11034.
Gepeert ist der MDIR mit dem CUL. Ich hatte vorab gelesen das dieser
nicht extra mit der VCCU gepeert werden muss.
Ich hatte aber hier noch etwas gestöbert und war in einem anderen Beitrag
auf den Bewegungsmelder gestoßen wobei dort auch ein noConfig stand dieses
aber nicht das eigentliche Problem war.
Ich habe dann die dort gepostete cfg auf meinen MDIR angepasst und jetzt schaltet
er auch ohne im Log das noConfig aufzuführen.
http://forum.fhem.de/index.php/topic,27586.msg210832.html#msg210832
Gruß
ZitatIch hatte vorab gelesen das dieser nicht extra mit der VCCU gepeert werden muss.
korrekt - wenn die CUL zur vccu gehört und somit die gleiche HMID hat.
Die meinst sicher gepairt.
Du kannst aber eine Kanal in der vccu anlegen und den MDIR peeren, also den Kanal mit dem Kanal.
Du hast mit dem config wohl das peering des vccu-channels eingerichtet (bei virtuellen geht das auch über Config, wenn auch nicht empfohlen)