HM virtual CCU

martinp876 · 28 April 2014, 20:28:12

Hi,

ich habe einmal eine virtuelle CCU gebastelt. Ich denke, die ist sinnvoll, um die Eigenschaften nachzubilden... u.a. die Kanäle, welche auch HM in der CCU angibt.
Komplett ist es noch nicht. Der Betrieb sollte aber gefahrlos funktionieren. Doku wird nachgezogen, falls es anklang finden.
Anlegen: Die HMID sollte die eines IO devices sein.

Code Auswählen

define ccu CUL_HM HMId
attr ccu model CCU-FHEM

Die CCU führt dabei ein set ccu update aus, was man jederzeit noch einmal manuel anstossen kann.
In der CCU werden alle IOs angezeigt, die auf diese HMId reagieren (also diese eingetragen haben).
Man kann bis zu 50 Channels definieren. Bei Update werden peers gesucht, die zur CCU gehören (also deren ID haben) und als Channels angelegt. Diese Channels sind virtuelle Channels und können als Buttons genutzt werden. Sie haben nicht alle Funktionen der allgemeinen virtuellen Channels (SDTeam, virtualTC,...) sondern nur die, die auch HM anbietet - also ein Button mit press long/short.

Die Zustandsänderung des HMLAN (disconnect/oderload) wird automatisch im state der CCU angezeigt. Das gilt aktuell nicht für die CUL.

Im IO gibt es ggf ein internal owner_CCU, das auf die "ccu" zeigt.
Mittelfristig würde ich dann wünschen, das eine CCU immer eingerichtet wird, wenn man entsprechende Kanäle peeren will. peerIODev würde dann gestrichen werden.
Gruss Martin

der-Lolo · 28 April 2014, 20:51:02

hallo martin,
kann man mithilfe dieser CCU auf long/short eines HM-LC-Sw1PBU-FM in FHEM reagieren?

betateilchen · 28 April 2014, 21:01:15

~~muss ich die Anzahl der Channels manuell setzen?~~

ich ziehe die Frage zurück, nachdem ich eben auf SVN war

betateilchen · 28 April 2014, 21:13:08

(http://up.picr.de/18117659ij.jpg)

Wenn ich da jetzt ein "press short" auslöse, bedeutet das, dass quasi alle in peerList stehenden Fernbedienungsbutton gleichzeitig gedrückt werden?

betateilchen · 28 April 2014, 21:23:11

uiuiui...

Die virtuelle ccu hat gerade dazu geführt, dass mein gesamtes Homematic Equiment nicht mehr funktioniert, weil es so mit messages zugeballert wird, dass plötzlich z.B. sämtliche Tür- und Fenstermelder auf RESPONSE TIMEOUT:RegisterRead stehen.

martinp876 · 29 April 2014, 09:26:09

Zitatkann man mithilfe dieser CCU auf long/short eines HM-LC-Sw1PBU-FM in FHEM reagieren?

nein - die Kanäle simulieren Buttons, keine Aktoren. Der Sw1PBU sendet sowieso keinen trigger, da kann man (ohne SW änderung im PBU) nie reagieren.
Der PBU würde auf einen ButtonPress des CCU-Buttons reagieren.

Zitatmuss ich die Anzahl der Channels manuell setzen?

für die, die nicht in SVN waren:
Man definiert die Buttons "manuell" - mit virtuell, gibt also die Anzahl der gewünschten Buttons an. Mit Update werden darüber hinaus alle gepeerten Buttons "gesucht" und eingerichtet. (auch mit Lücken in der Button-liste)

ZitatWenn ich da jetzt ein "press short" auslöse, bedeutet das, dass quasi alle in peerList stehenden Fernbedienungsbutton gleichzeitig gedrückt werden?

ja - das ist die Idee und das Vorgehen. Du hast aber sehr viele Aktoren auf Button 1 gepeert.
Du solltest es eigentlich auch in deiner CCU2 entsprechend sehen.

ZitatDie virtuelle ccu hat gerade dazu geführt, dass mein gesamtes Homematic Equiment nicht mehr funktioniert, weil es so mit messages zugeballert wird, dass plötzlich z.B. sämtliche Tür- und Fenstermelder auf RESPONSE TIMEOUT:RegisterRead stehen.

was hast du gemacht? Nichts oder ein Press des Button 1 mit den vielen Peers? Damitt ich es testen kann.
Seltsam ist, dass du offenbar Buttons mit dem CCU-Button gepeert hast. Hm - das könnte ich abfangen - das sind "sonder-peers". Die antworten NIE auf ein press - klar. Wenn es auch noch burst-devices sind, könnte HMLAN/USB überlastet werden.
Bitte mehr Details

Gruss Martin

betateilchen · 29 April 2014, 09:40:23

Hallo Martin,

ich weiss nicht, ob Du Dich an unser gemeinsam gelöstes Problem vor ein paar Monaten erinnerst, als die ersten RC-4-2 auf den Markt kamen und es lange das Problem gab, dass ich nicht zuverlässig eine grüne Bestätigung für die Fernbedienungsbuttons gab. Auch nicht mit virtuellen Aktoren.

Die Lösung war seinerzeit, die Fernbedienungsbuttons direkt mit dem HMUSB zu peeren, was völlig problemlos funktionierte und seither auch immer die korrekte Rückmeldung liefert. Aus dieser Erfahrung heraus werden beim mir immer alle Fernbedienungsbuttosn mit HMUSB gepeert. Und diese gepeerten Buttons tragen ALLE die HMID 12700001 (quasi Channel 01 des HMUSB) in ihrer peerList.

An diesem Vorgehen möchte ich ungerne etwas ändern - es funktionieren auf diese Weise nämlich alle Fernbedienungen und Wandtaster genau so wie ich es möchte, einschließlich der gewünschten optischen Rückmeldungen per LED.

Was ich gestern abend gemacht hatte, um die Überlast zu erzeugen: Ich habe für den Btn_1 ein press short ausgeführt. Mit fatalen Folgen

strauch · 29 April 2014, 10:36:03

Sorry ich muss mal ganz doof Fragen, was ist Sinn und Zweck der virtuellen CCU?

In meiner kleinen Homematicwelt bei mir im Kopf war das bisher so gedacht: CCU = Homematic Zentrale. FHEM = Ersatz für Homematic Zentrale. Also war für mich beim Einsatz von FHEM eine CCU überflüssig..... des scheint ja nun nicht so zu sein?!

betateilchen · 29 April 2014, 10:44:53

Doch, das ist schon so.

Die von martin jetzt experimentell eingebaute CCU wird wohl irgendwann integraler Bestandteil für Homematic Komponenten innerhalb von fhem - aber es bleibt eine reine Softwarelösung innerhalb fhem. Im Moment ist der erste Schritt getan - mal schauen, was noch alles angedacht ist.

Sinn und Zweck? Da fällt mir schon einiges ein, aber da meistens genau das Gegenteil von dem passiert, was ich mir vorstelle, sag ich hier jetzt lieber nix

martinp876 · 29 April 2014, 11:22:12

ZitatDie Lösung war seinerzeit, die Fernbedienungsbuttons direkt mit dem HMUSB zu peeren, ....
An diesem Vorgehen möchte ich ungerne etwas ändern...

alles klar - sollte kein Problem sein.
Was ich aktuell nicht plane ist, diese CCU-Buttons als Aktor auszuführen. Es werden also keine Zustände gespeichert. Wenn du den Button der RC4 drückst sollte es aber ein Reading "trigger" geben...

ZitatWas ich gestern abend gemacht hatte, um die Überlast zu erzeugen: Ich habe für den Btn_1 ein press short ausgeführt. Mit fatalen Folgen

das war zu erwarten (nun, ich hatte es nicht bedacht, dass Buttons hier gepeert werden) - zumindest, dass es Probleme gibt.
Ich werden einbauen, das "press" von virtuellen Entites nur an Aktoren gesendet wird. Muss ich aber erst noch basteln.

ZitatSorry ich muss mal ganz doof Fragen, was ist Sinn und Zweck der virtuellen CCU?

zum einen hat man hier ein Abbild einer CCU, die ihre IOs verwaltet. Das gibt schon einmal ein realeres Bild der Anlage, indbesondere bei mehreren IOs. Denkbar wären auf dieser Basis Ersatzschaltungen von IO devices
Ausserdem kann man jetzt die Buttons der Zentrale wirklich bearbeiten. Peeren, press, Config checks.
Man kann mehrere CCUs erstellen... wenn man will und dies für sinnvoll erachtet.
Was schon immer unschön und kompliziert ist, ist das unsaubere handling der HMId der IO devices - das ist ausserhalb einer Kontrolle von CUL_HM - was keinen sinn macht.
Vielleicht erfahren wir auch noch die ideen von Betateilchen - damit ich es anders machen kann

betateilchen · 29 April 2014, 11:35:21

Zitat von: martinp876 am 29 April 2014, 11:22:12Wenn du den Button der RC4 drückst sollte es aber ein Reading "trigger" geben...

jepp.

betateilchen · 29 April 2014, 13:06:25

Wieso versucht fhem eigentlich seit neuestem permanent, ein RegisterRead an HM Komponenten zu schicken, wo es überhaupt keinen Sinn macht?

(die fhemccu habe ich natürlich wieder gelöscht, die kann es nicht sein)

martinp876 · 29 April 2014, 13:09:08

das Press sollte jetzt nur an solche gehen, die es auch verstehen (in SVN)

ZitatWieso versucht fhem eigentlich permanent, ein RegisterRead an HM Komponenten zu schicken, wo es überhaupt keinen Sinn macht?

was soll ich sagen -
macht es nicht?
nicht bei mir?
permanent schon garnicht?
macht doch sinn?

lass schon raus - welche register sollen von welchen Device gelesen werden und wann?

betateilchen · 29 April 2014, 13:11:21

das weiss ich noch nicht. Ich weiss nur, dass seit gestern abend alle meine Fensterkontakte permanent einen Timeout:RegisterRead melden und ich keine Werte mehr habe, die ich im RSS darstellen kann.

martinp876 · 29 April 2014, 13:21:43

könnte mit einem Bug zu tun haben - der Transmit mode war falsch berechnet.
Ist schon behoben (heute).
Dann wäre es so, dass das Register lesen gescheduled war, aber nie ausgeführt wurde, es sein den du drückst Config. Die falsche Berechnung hat das Device als "always" markiert - FHEM hat also versucht, den Auftrag auszuführen.

Kann es so gewesen sein?