CCU2 neben FHEM

[zap]

HM IP über die CCU2? Das wäre mir aber neu bzw. angenehm ...

geht nich Gips nich ...

Soll in Q4/2015 kommen.

[Pfriemler]

Hach. Wird kein Spaziergang. Dennoch: für meinen Anwendungsfall vielleicht machbar ... Zentrales Bedienpanel plane ich sowieso nicht, und letztlich sind ein Dutzend Werte von HM für FHEM intern relevant, die kann ich ggf. auch von der CCU2 aus schicken, dann bliebe der HMLAN aus. Ist eigentlich doof, zwei Zentralen wenn man eine haben kann.
An die Angriffe hatte ich noch gar nicht gedacht ...


geht nich Gips nich ...

[mgernoth]

Hallo,

letztlich sind ein Dutzend Werte von HM für FHEM intern relevant, die kann ich ggf. auch von der CCU2 aus schicken, dann bliebe der HMLAN aus.

Das geht wahrscheinlich am besten mit zaps oder henryks Modul. Ansonsten kannst Du auch Fhem eine andere HMID geben, dann lauscht es sicher nur passiv mit. Und selbst wenn Fhem senden sollte, wird es von den Geraeten ignoriert.

Viele Gruesse
  Michael

[martinp876]

Dem hmlan muss man jedes device einzeln bekannt machen, dann werden acks automatisch gesendet.
Hat man mehr hmlan darf man das device nur einem hmlan bekannt machen. Die vccu leistet das, also eintragen und löschen der IDS in den IOS.
Man könnte ein dummy io einrichten und es dem device als io zuordnen. Dann kann man nicht mehr senden, was gewünscht ist. Parallel ist schwierig. Attack geht garnicht zu erkennen

[Pfriemler]

@Martin: is ne gute Idee - aber funktioniert das? Ein zugeordnetes IO zu einem HM-Gerät legt doch m.W. nur eine (bevorzugte) Sende-IO fest - das ACK sendet doch aber stets das empfangende IO? So könnte man zumindest verhinden, dass FHEM mit dem HM willentlich redet.
Martin, isses in der Tat so, dass das HMLAN eine Liste der Pair-Partner geschickt bekommt und dann autark ACKs sendet?

Hingegen finde ich Michaels Idee spannend - wenn ich mich recht entsinne, sind "Fremdgeräte" etwa vom Nachbarn schon immer ein "Störfaktor" in FHEM - also ist Mitlesen des Status anscheinend kein Thema. Und wenn sich das HMLAN an sich nicht angesprochen fühlt, sollte es auch keine ACKs schicken ... und wenn es reden will oder soll, ignorieren die HM-Geräte den Fremdling mit der falschen ID sowieso.

[zap]

Hallo,

Das geht wahrscheinlich am besten mit zaps oder henryks Modul. Ansonsten kannst Du auch Fhem eine andere HMID geben, dann lauscht es sicher nur passiv mit. Und selbst wenn Fhem senden sollte, wird es von den Geraeten ignoriert.

Viele Gruesse
  Michael

Der Vorteil vom HMRPC Modul ist, dass es die RPC Schnittstelle der CCU anzapft bzw. sich dort registriert. Dadurch bekommt es Änderungen in der CCU (Status der Geräte) sofort mit. HMCCU hingegen muss aktiv die CCU pollen oder man muss von der CCU aus einen Trigger an FHEM schicken (z.B. per netcat auf den Socket Port von FHEM).

HMRPC ist allerdings mit Vorsicht zu genießen, da die Implementierung von RPC nicht vollständig ist.. So werden z.B. Nachrichten von der CCU nicht bzw. nicht korrekt bestätigt. Das führt zu vielen Fehlermeldungen im Syslog der CCU. Ich habe das nie richtig zum Laufen bekommen und daher HMCCU entwickelt.

[martinp876]

Das empfangende io? Funk ist broadcast. Es wird immer alles empfangen, selbst die Adresse ist egal.
Ja, die hmlan,hmusb werden mit den IDS der device versorgt. Cul natürlich nicht, die unterstützt das nicht. Bei iowechsel wird die ID in einem gelöscht und im 2. gesetzt.
Wie sollte es sonst funktionieren, zwei hmlan an einem system zu betreiben? Die ccu2 macht das identisch. Ausser, dass ich nicht gesehen habe, dass sie einen Automodell unterstützt. Das ist bei plug&play etwas kompliziert.
Du kannst ein io mit der hmid der vccu anlegen, es nicht der vccu zuordnen. Das device setzt attr iodev des io, auch hier nicht der vccu zuordnen. Nun hast du ein dummy io mit ID der zentrale. Du könntest im io noch dummy setzten, dann wird nicht nach ihm gesucht.

[Pfriemler]

Nur mal so'n Zwischenbericht:
Zentrale läuft und ich paire nach und nach die HM-Geräte von FHEM auf die CCU2 um. Dann gibt es ATTACKs bis zu einem FHEM-Neustart - dann ist Ruhe. Die Definitionen lasse ich in FHEM stehen, ändere nur "autoReadReg" auf 0-none - die Geräte hören ja eh nicht mehr auf FHEM und HMLAN, also hat das Registeauslesen eh keinen Zweck.
Der Status der HM-Geräte wird aber sauberst und flink mitgelesen und angezeigt (schneller als auf der CCU2). Keine Fehler, nichts. Nun fehlt mir nur noch eine Steuermöglichkeit von FHEM aus, aber das ist ja prinzipiell klar.

[martinp876]

Warum auch Fehler? Fhem ist ein Spion. Sollten sich devices steuern lassen ist es ein bug in der fw. Wenn fhem die ID der zentrale bekommt kannst du auch steuern.
Alles schon durch gesprochen.
Den Sinn verstehe ich nicht. Entweder nutze ich die ccu. Oder ich steuerte die ccu durch fhem. Oder ich erweitere fhem um den Komfort der ccu zu erhalten. Aus meiner Sicht ist das erreicht. Wenn man templates einsetzt, sinnvoll, ist man sogar weit ueberlegen. Was die verknuepfbarkeit angeht auch mit anderen Systemen kommt die ccu garnicht mit.
Nettes Experiment, den Sinn werde ich nie verstehen. Aber jeder wie er will

[Pfriemler]

Ich habe das nur als Hinweis platziert, dass es einfach ist und kein Hexenwerk, FHEM als "Spion" mitlaufen zu lassen und so den Status einzelner Geräte quasi ohne Anfrage bei der CCU2 mitzubekommen. Obendrein ist FHEM in der Aktualisierung schneller als das Webinterface der CCU2.

Wenn FHEM die ID der Zentrale bekommt, hagelt es ATTACKS. Das kann keine Lösung sein.

Nettes Experiment, den Sinn werde ich nie verstehen. Aber jeder wie er will

Sagtest Du schon, verlangt auch keiner. Ich will einfach alles, was Homematic unter sich ausmachen will, auslagern. Für mich wäre das ein Produktivsystem und FHEM das Sahnehäubchen - und alles läuft, wenn ich FHEM mal versehentlich totkonfiguriert habe...

[martinp876]

Wenn FHEM die ID der Zentrale bekommt, hagelt es ATTACKS. Das kann keine Lösung sein.

dann ist es ein Fehler. Die Attacks sollte es auch Hageln, wenn die CCU an devices einstellungen vornimmt, von welchen FHEM vermutet dass sie ihr gehören.

ansonsten, wie gesagt: jeder wie er will.

[Pfriemler]

dann ist es ein Fehler. Die Attacks sollte es auch Hageln, wenn die CCU an devices einstellungen vornimmt, von welchen FHEM vermutet dass sie ihr gehören.

War das WE weg ...
Ich habe meine HM-Devices von FHEM geunpairt und an der Zentrale mit differierender ID angemeldet. FHEM weiß also, dass die Geräte nicht mehr FHEM "gehören". Dadurch erkennt das HMLAN auch keine fremden Funktelegramme der FHEM-ID und sendet keine Attacks. Alle ACK kommen nur noch von der CCU.
Die bisher mit FHEM gepairten Geräte werden jedoch trotzdem in ihren Statusmeldungen weiter problemlos mitgelesen.

Eine Steuerung von FHEM direkt funktioniert jetzt natürlich nicht, aber das ist ja auch nicht von mir vorgesehen. Dafür sende ich dann Befehle an die CCU, die das erledigt.

[martinp876]

Muss ich erlich gesagt nachsehen. Korrekt ist es aber so nicht.
Fhem kümmert sich nicht darum, ob gepairt ist oder nicht. Das interessiert das device.
Fhem gleicht es mit der ID des assigned io ab.
Hminfo sollte merken, wenn pairedto nicht dem io entspricht.
Fhem geht bei allen devices die nicht ignore sind davon aus, das sie dazu gehören.
Einen sniffermode gibt es in der Form nicht.

[Pfriemler]

Muss ich erlich gesagt nachsehen. Korrekt ist es aber so nicht.

Schade. Mir gefällt der Zustand so sehr gut.

Fhem kümmert sich nicht darum, ob gepairt ist oder nicht. Das interessiert das device.

Dem Device ist es erst mal auch ziemlich egal. Es arbeitet stand-alone, bis sich eine Zentrale als Herr und Meister meldet.

Hminfo sollte merken, wenn pairedto nicht dem io entspricht.

Das blieb anfangs auf der FHEM-ID stehen (und in R-pairCentral stand "set_0x000000"). Nach ein paar Neustarts kann ich nun feststellen, dass z.B. meine SCo's brav in PairedTo "0x000000" melden (und nicht etwa die ID der CCU2). Für meinen Dimmer im Esszimmer sieht FHEM aber noch immer

Code Auswählen Erweitern

Internals:
   DEF        266A77
   HMLAN1_MSGCNT 17
   HMLAN1_RAWMSG E266A77,0000,8CBCC8AB,FF,FFC1,A9A410266A773B4DAD060100008000
   HMLAN1_RSSI -63
   HMLAN1_TIME 2015-11-18 21:29:30
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     17
   NAME       WzDimmer1
...
   channel_01 EsstischLampe
...
   protState  CMDs_done_Errors:1
...
   Readings:
...
     2015-07-06 04:03:58   PairedTo        0x1411AB
...
     2015-11-11 00:17:02   R-pairCentral   set_0x000000

Ein Auslesen der Register des Dimmers via FHEM funktioniert auch nicht mehr - der Dimmer ignoriert den Befehl ja (sieht so aus als wenn er von einer fremden Zentrale käme). So bleibt R-pairCentral wohl für immer auf "set_0x000000" stehen ...

Natürlich bekommt FHEM mit, dass die mit der CCU verheirateten Geräte z.B. mit dieser reden ("contact     closed (to CCU2)") (wobei CCU2 bei mir ein HM-Dummy mit der ID der CCU ist). Insofern kann ich zumindest bei den SCo's keinen Unterschied zwischen einem Gerät feststellen, welches etwa per Autocreate (oder manuell) in  FHEM angelegt, aber noch nicht gepairt wurde (außer dass hier die Pakete an broadcast gehen), und meinen von FHEM abgelernten Geräten. Auch bei den Pair-Fehlversuchen, bei denen das Device den Paarungsbefehl partiell "missachtet", würde man bei ATTACKs eher hellhörig werden.

Einen sniffermode gibt es in der Form nicht.

Ich würde das Verhalten eher mit "Einbahnstraßen-Geräten" vergleichen, wie etwa WS-Sensoren über einen CUL. Hier protokolliert FHEM für ein einmal angelegtes Gerät alle Statusmeldungen mit, ohne überhaupt eine Chance zur Gegenreaktion zu haben. So ähnlich ist es hier. Ich darf natürlich nicht versuchen, das Gerät aktiv zu steuern. Dann wächst der cmd_error-Stapel ...

Fhem geht bei allen devices die nicht ignore sind davon aus, das sie dazu gehören.

Verstehe ich.

Hminfo sollte merken, wenn pairedto nicht dem io entspricht.

Das ist in der Tat ein Schönheitsfehler - die Liste der möglichen Fehler ist jetzt schon ellenlang, exemplarischer Auszug:

Code Auswählen Erweitern

peer list incomplete. Use getConfig to read it.
    incomplete: HM_UWS1:
    incomplete: OGNFenster:
    incomplete: OGOFenster:
    incomplete: OGWFenster:

peer not defined
    FB4Alarm_disarm id:ABC12301

PairedTo missing/unknown
    CCU2
    OGNFenster
    OGOFenster
    OGWFenster

PairedTo mismatch to IODev
    8BattAktor1 paired:set_0x000000 IO attr: 1411AB.
    EGHaustuer paired:0x000000 IO attr: 1411AB.
    EGWzTerassentuer paired:0x000000 IO attr: 1411AB.
    EnMonitorStecker1 paired:set_0x000000 IO attr: 1411AB.
    FB4V paired:0x000000 IO attr: 1411AB.
    OGBadFenster paired:0x000000 IO attr: 1411AB.
    SchalterSensorSCI3_1 paired:0x000000 IO attr: 1411AB.
    WzDimmer1 paired:set_0x000000 IO attr: 1411AB.


Last but not least: ATTACKs sollte es eigentlich nur dann geben, wenn FHEM bzw. das entsprechende IO feststellen, dass Pakete unterwegs sind, die als Absender die eigene ID tragen, aber definitiv nicht von FHEM stammen (wie wenn jemand mit einer zweiten Zentrale gleicher ID die Geräte zu kapern versucht). Meine "umgelernten" Geräte sollte FHEM wie "welche vom Nachbarn" behandeln - tut es ja auch, ist für mich kein Fehler.

[martinp876]

Pairedto ist sicher falsch.
Fhem dekodiert das lesen der Register, auch wenn die ccu diese liest. Wenn fhem etwas nicht mit bekommt oder die Register nach dem lesen nicht gespeichert werden ist der Inhalt unsicher. Ich klassifizieren die Register somit als zufällig und unzuverlässig.

Der mode ist ein reiner sniffermode. Du kannst nur lauschen. Mit ein paar Tricks könntest du virtuelle tasten in fhem definieren und trigger auslösen. Das einrichten wird aber holprig, da eines über die ccu machen must.

Einem wettersensor lauscht man auch nur. Man kann nichts einstellen, ist also sniffen.

Ich muss dummy noch einmal ansehen. War eine alternative zu ignore, lange her.

Was immer du machen willst mit den gesammelten daten