Anleitung zum auslesen von Homematic IP (AccessPoint) mit FHEM

[MadMax-FHEM]

Ich werde mich derweil mit anderem beschäftigen, ich habe da z.B. grade ein paar interessante ZigBee-Devices aus China im Zulauf, z.B. zwei (1 und 2-Kanal-) UP-Aktoren, die man scheinbar in europ. UP-Dosen hinter bestehende Schalter OHNE Nullleiter unterbringen kann (Stück <20 Euro). Da kannst du bei eQ-3 lange warten, bis die sowas in HM-IP anbieten... (Aber bei solchen Experimenten weiß man nie, ob es läuft und wenn ja, wie lange bzw. wie lange es dauert, bis der betr. Aktor in den Interface-Dienst integriert ist).

Welche wären das!?
Da hätte ich evtl. auch Interesse

Da kannst du bei eQ-3 lange warten, bis die sowas in HM-IP anbieten...

Ich glaube nicht, dass da (jemals) sowas kommt.
Gab es ja nicht mal bei Homematic "Classic", drum hatte ich ja "damals" auch noch IT drin...

Gruß, Joachim

[Beta-User]

Welche wären das!?
Da hätte ich evtl. auch Interesse

...auch darauf hätte ich wetten können, dass das jemand interessiert...

Typenbezeichnung ist u.A. QS-Zigbee-S05-L, findet man z.B. in der Bucht mit den Schlagworten "Tuya Zigbee 3.0 Wifi Smart Switch Drahtloses Fernschaltermodul Relais EU 220V" - Schaltleistung ist aber für Leuchtmittel (bis 100W) ausgelegt (ggf. sind das Mehrfachangebote mit unterschiedlichen Modellen!).

Überhaupt gibt es mit "Tuya Zigbee 3.0" seit kurzem noch mehr interessante Treffer, z.B. einen "Scene controller 4 gang" - ein 4-fach-Batterie-Taster (je einfach+Doppelklick und Lang (release?)); der könnte von den Außenmaßen her ggf. zu/in Jung CD passen...
Ist aber alles erst unterwegs, werde berichten .

[MadMax-FHEM]

...auch darauf hätte ich wetten können, dass das jemand interessiert...

Ich wollte dich nur nicht "enttäuschen"

Typenbezeichnung ist u.A. QS-Zigbee-S05-L, findet man z.B. in der Bucht mit den Schlagworten "Tuya Zigbee 3.0 Wifi Smart Switch Drahtloses Fernschaltermodul Relais EU 220V" - Schaltleistung ist aber für Leuchtmittel (bis 100W) ausgelegt (ggf. sind das Mehrfachangebote mit unterschiedlichen Modellen!).

Überhaupt gibt es mit "Tuya Zigbee 3.0" seit kurzem noch mehr interessante Treffer, z.B. einen "Scene controller 4 gang" - ein 4-fach-Batterie-Taster (je einfach+Doppelklick und Lang (release?)); der könnte von den Außenmaßen her ggf. zu/in Jung CD passen...
Ist aber alles erst unterwegs, werde berichten .

Werde ich mir mal anschauen...
...und bin gespannt!

Gruß, Joachim

[Horti]

Afaik kann man den AP auch "umflashen" und als IO für eine (virtuelle) CCU (für die Module HMCCU.*) verwenden.

Das ist so nicht ganz richtig. Man kann das Ding zwar umflashen und als Reichweitenverlängerung nutzen, aber nur zusätzlich zu dem RPI-RF-MOD als HMIP-Hauptfunkmodul.

Der billigste Weg zu einer virtuellen CCU fü HMIP ist HM-MOD-RPI-PCB, aufgesteckt auf einem Raspi, und piVCCU, damit der Raspi auch für andere Zwecke genutzt werden kann.

[Beta-User]

Hmm, ok, Danke für die Erhellung, Praxis schlägt Theorie...

Hatte ja geschrieben, dass ich nur vermute, dass das klappen könnte, und Alexander/deimos (?) war mir so im Ohr, dass piVCCU (z.B. auf x86-Systemen) auch ohne Pi-Modul lauffähig wäre, sofern nur irgendein (ggf. im LAN erreichbares) IO verfügbar ist, das die Timings beherrscht  (alternativ: per USB mit einem speziellen Adapter).

Eventuell sollte man mal ihn zu Rate ziehen, evtl. kann man da was tweaken. Grundsätzlich scheint das Teil im "Slave"-Modus aber nicht als Mesh-Repeater zu fungieren, sondern als eigenständiges IO - so deute ich jedenfalls das, was Jamo aaO. berichtet hat - und damit müßte es eigentlich prinzipiell als einzige Funkschnittstelle auch tauglich sein.

Soweit meine Theorien, viel Freude noch an HM-IP...

[frank]

Das ist so nicht ganz richtig. Man kann das Ding zwar umflashen und als Reichweitenverlängerung nutzen, aber nur zusätzlich zu dem RPI-RF-MOD als HMIP-Hauptfunkmodul.

das "umflashen" habe ich in der anleitung eher als "fw-update" des accesspoint verstanden.

bist du dir sicher, dass die "ccu" dann wirklich noch den hmuart benötigt?

laut anleitung soll der vorteil des accesspoint als router ja sein, dass der dutycycle des "normalen" funkmoduls nicht belastet wird. dann kann es ja eigentlich kein herkömmliches "routing" über funk sein, wie zb bei den steckdosen.

somit hätte ich den verdacht, dass es auch nur mit accesspoint funktionieren könnte.

es wäre ja auch seltsam, dass wenn das "normale" funkmodul ausfällt, dadurch dann auch alle accesspoint router nutzlos wären.

ich denke, ich muss mir mal einen accesspoint besorgen.

[Horti]

Hatte ja geschrieben, dass ich nur vermute, dass das klappen könnte, und Alexander/deimos (?) war mir so im Ohr, dass piVCCU (z.B. auf x86-Systemen) auch ohne Pi-Modul lauffähig wäre, sofern nur irgendein (ggf. im LAN erreichbares) IO verfügbar ist, das die Timings beherrscht  (alternativ: per USB mit einem speziellen Adapter).

Es geht nichts über gesundes Halbwissen Ja, der Alexander hat 2 (besser gesagt 3) Platinen entwickelt, um die Funkmodule RPI-RF-MOD oder HM-MOD-RPI-PCB in der CCU über USB oder WLAN einzubinden. Insofern nicht "irgendein" IO-Device und nicht "irgendwie" erreichbar.

Eventuell sollte man mal ihn zu Rate ziehen, evtl. kann man da was tweaken. Grundsätzlich scheint das Teil im "Slave"-Modus aber nicht als Mesh-Repeater zu fungieren, sondern als eigenständiges IO - so deute ich jedenfalls das, was Jamo aaO. berichtet hat - und damit müßte es eigentlich prinzipiell als einzige Funkschnittstelle auch tauglich sein.

Für HMIP gelten strenge Vorgaben bzgl. Signallaufzeit, deswegen scheidet WLAN von vornherein aus. Deswegen kann man da auch nicht "was tweaken", auch "sollte man mal ihn zu Rate ziehen" kann man sich sparen, er hat das oft genug erläutert.

das "umflashen" habe ich in der anleitung eher als "fw-update" des accesspoint verstanden.

Laüft ja aufs Gleiche hinaus, es muss eine andere/neue Firmware drauf.

bist du dir sicher, dass die "ccu" dann wirklich noch den hmuart benötigt?

Ich bin mir sehr sicher, dass man noch das RPI-RF-MOD braucht als Hauptfunkmodul, hmuart reicht dafür nicht. Ob es technisch notwendig ist, oder eq-3 den Absatz von RPI-RF-MOD steigern möchte, vermag ich nicht zu beurteilen.

laut anleitung soll der vorteil des accesspoint als router ja sein, dass der dutycycle des "normalen" funkmoduls nicht belastet wird. dann kann es ja eigentlich kein herkömmliches "routing" über funk sein, wie zb bei den steckdosen.

somit hätte ich den verdacht, dass es auch nur mit accesspoint funktionieren könnte.

es wäre ja auch seltsam, dass wenn das "normale" funkmodul ausfällt, dadurch dann auch alle accesspoint router nutzlos wären.

ich denke, ich muss mir mal einen accesspoint besorgen.

s. oben, sinnvoll oder nicht, aber RPI-RF-MOD ist eine zwingende Voraussetzung. Angeblich, weil irgendeine HW-Komponente davon mit für die Verschlüsselung genutzt wird, wie auch schon beim HMIPW. Dass es nicht mit HM-MOD-RPI-PCB geht, kann ich aus eigener Erfahrung bestätigen, ich habe hier nämlich schon einen HAP liegen.

[Beta-User]

Ok, dein Wissen geht über mein Halbwissen raus, auch wenn das mit den Latenzen mAn. erst ab der Funkschnittstelle gilt (sofern das IO kein "dummes" IO ist, wie das bei einem Pi-PCB+ESP8266 der Fall ist)...

Mind. ein Grund mehr, sich mit Alternativen zu den proprietäten Lösungen von eQ-3 zu beschäftigen... Ich mache dann mal weiter mit ZWave und ZigBee . Auch jweils nicht ganz einfach, aber günstiger, teils flexibler und zumindest besser standardisiert bei größerer Auswahl (auch, was Anbieter angeht). Bin dann mal raus.

[Horti]

Ok, dein Wissen geht über mein Halbwissen raus, auch wenn das mit den Latenzen mAn. erst ab der Funkschnittstelle gilt (sofern das IO kein "dummes" IO ist, wie das bei einem Pi-PCB+ESP8266 der Fall ist)...

Es gilt ab der Schnittstelle, mit der man sich ins System einklinkt, und die ist wohl (Achtung, Halbwissen ) ziemlich nah an der Funkschnittstelle. Und da die CCU kein Open Source ist und eq-3 wenig Motivation hat, an der Schittstelle was zu ändern, gelten diese Vorgaben für die ganze Strecke ab der CCU.

[Beta-User]

Na ja, ich kapiere es halt vermutlich einfach mal wieder nicht:
Der hier in Rede stehende AP wird doch nicht unbedingt über WLAN eingebunden, das geht auch via LAN, oder? Da sind die Latenzen zwar auch gegeben, aber eben tendenziell deutlich besser (was die Laufwege zwischen dem Prozessor für z.B. DebMatic und der eigentlichen Funkschnittstelle (auf dem AP) betrifft; ob das für die "magischen 5ms" in toto reicht (https://forum.fhem.de/index.php/topic,97295.msg905065.html#msg905065) kann ich nicht beurteilen, und ob das auch (noch?) gilt, wenn man ein "intelligentes" abgesetztes IO nutzt, ist eine weitere Frage.

Vermutlich hast du aber dahingehend recht, dass die DebMatic (das dürfte wenn, dann die besten Aussichten auf Erfolg bieten) irgendwo eine Art "Identitätsspeicher" haben muss, um den "Master-Key" für das ganze zu speichern. Dass dafür uU. ein "entferntes IO" nicht taugt, kann durchaus sein - das war afaik auch bei BidCoS nicht wesentlich anders - da konnte man ihn aber irgendwo eintragen.

Bin mal gespannt, ob unsere cracks@hm da irgendeinen Weg finden, das Ding "solo" nutzbar zu machen, ansonsten scheint es ja auch keine schlechte Idee zu sein, so ein Teil zur Reichweitenvergrößerung einzusetzen...

Aber jetzt wirklich: habe fertig
(Wollte doch eigentlich nur anmerken, dass es für einen noob keine gute Idee ist, sich auf experimentelles Eis zu begeben ... Man kann da zwar unheimlich viel lernen, aber das Risiko ist eben hoch, dass man über irgendwas stolpert .)

[Horti]

Ich bin ja bei Dir, dass es technisch möglich sein müsste, den AP als HMIP-IO-Device zu nutzen. Aber das Szenario wird von eq-3 nun mal nicht unterstützt. Und um das an eq-3 vorbei zu machen, kann man zwar das Funkmodul über (W)LAN/USB oder was auch immer absetzen, nur muss man dann für die ganze Strecke die gleichen Vorgaben erfüllen, die für das Funkmodul alleine gelten, wenn es direkt an der CCU hängt. Das hat der Alex zwar auch geschafft mit seinen Platinen, aber man kann nicht zu lange Kabeln oder zu viele Hops dazwischen haben. Eine konkrete Grenze kenne ich nicht, aber ich wollte halt nur Deine Aussagen "irgendein IO" und "was tweaken" relativieren.

Aber von mir aus müssen wir das auch nicht weiter vertiefen, ich wollte nur die akltuelle Lage darstellen.

[zap]

Dem HmIP AP fehlt insbesondere der RPC Stack der CCU. Daher kann der AP lediglich als LAN Gateway eingesetzt werden. Analog zum BidCos LAN-Gateway. Diese Gateways werden in der CCU konfiguriert. Man kann in der CCU auch bestimmte HM Komponenten diesen Gateways zuordnen. Die Kommunikation läuft dann zwischen Gateway und HM Komponente.
Für einen RPC Client (wie HMCCU) ist das alles transparent, d.h. single point of contact ist die CCU. Von den LAN-Gateways sieht FHEM/HMCCU nichts (muss es auch nicht).

Um einen HmIP AP als LAN-Gateway nutzen zu können, muss zunächst die CCU auf die neuste Firmware aktualisiert werden. Dann findet man unter Einstellungen > Systemsteuerung den neuen Button "Accesspoints mit inkompatibler Firmware". Damit kann man die Firmware des HmIP APs aktualisieren und anschließend anlernen und als LAN Gateway einrichten.

[Beta-User]

Kurzfassung also doch:

Geht (ohne weitere Hardware), wenn man z.B. als CCU eine DebMatic (geht auch auf demselben Server) aufsetzt?

[Horti]

Kurzfassung also doch:

Geht (ohne weitere Hardware), wenn man z.B. als CCU eine DebMatic (geht auch auf demselben Server) aufsetzt?

NEIN:
https://homematic-forum.de/forum/viewtopic.php?f=26&t=60444&p=604909#p605804

https://github.com/jens-maus/RaspberryMatic/wiki/Einleitung#vorraussetzungen:

HmIPW-DRAP    LAN HmIP-Wired Access Point             :heavy_check_mark:    RPI-RF-MOD notwendig

[Christoph Morrison]

Von den LAN-Gateways sieht FHEM/HMCCU nichts (muss es auch nicht).

Ich weiß was du meinst, aber natürlich existiert das LAN-GW/der HmIP-HAP als Device:

Code Auswählen Erweitern


Internals:
   .FhemMetaInternals 1
   CFGFN      ./cfg.d/general/interfaces/homematic/gateway.cfg
   DEF        general.interfaces.homematic.gateway.0
   FUUID      5fa0156b-f33f-0f53-c1d7-bb0f323643452f86
   FVERSION   88_HMCCUDEV.pm:v4.3.12-s21452/2020-03-19
   IODev      general.interfaces.homematic.ccu3
   NAME       general.interfaces.homematic.gateway.0
   NR         314
   STATE      <table>
    <tr>
        <th style="text-align: left;">Duty Cycle</th>
        <td>1.00 %</td>
    </tr>
    <tr>
        <th style="text-align: left;">CSMA Level</th>
        <td>2.00 %</td>
    </tr>
    <tr>
        <th style="text-align: left;">Erreichbarkeit</th>
        <td><span style="color: green";>Erreichbar</span></td>
    </tr>
    <tr>
        <th style="text-align: left;">Lokale Adresse</th>
        <td>192.168.0.148</td>
    </tr>
</table>
   TYPE       HMCCUDEV
   ccuaddr    0003DB3393B150
   ccudevstate active
   ccuif      HmIP-RF
   ccuname    general.interfaces.homematic.gateway.0
   ccutype    HmIP-HAP
   channels   1
   firmware   2.2.18
   statevals  devstate
   .attraggr:
   .attrminint:
   .userReadings:
     HASH(0x55c71cdc0ec8)
   Helper:
     DBLOG:
       activity:
         general.system.log.db:
           TIME       1604610940.00926
           VALUE      alive
       carrier_sense_level:
         general.system.log.db:
           TIME       1604610940.00926
           VALUE      2.000000
       config_pending:
         general.system.log.db:
           TIME       1604610940.00926
           VALUE      false
       duty_cycle:
         general.system.log.db:
           TIME       1604610940.00926
           VALUE      false
       duty_cycle_level:
         general.system.log.db:
           TIME       1604610940.00926
           VALUE      1.000000
       install_test:
         general.system.log.db:
           TIME       1604610940.00926
           VALUE      true
       ip_address:
         general.system.log.db:
           TIME       1604610940.00926
           VALUE      192.168.0.148
       reachable_formatted:
         general.system.log.db:
           TIME       1604610940.00926
           VALUE      <span style="color
       state:
         general.system.log.db:
           TIME       1604610936.67333
           VALUE      clear
   READINGS:
     2020-11-05 22:15:40   activity        alive
     2020-11-05 22:15:40   carrier_sense_level 2.000000
     2020-11-05 22:15:40   config_pending  false
     2020-11-05 22:15:40   duty_cycle      false
     2020-11-05 22:15:40   duty_cycle_level 1.000000
     2020-11-05 22:15:40   install_test    true
     2020-11-05 22:15:40   ip_address      192.168.0.148
     2020-11-05 22:15:40   reachable_formatted <span style="color: green";>Erreichbar</span>
   hmccu:
     devspec    general.interfaces.homematic.gateway.0
     dp:
       0.CARRIER_SENSE_LEVEL:
         OSVAL      2.000000
         OVAL       2.000000
         SVAL       2.000000
         VAL        2.000000
       0.CONFIG_PENDING:
         OSVAL      0
         OVAL       0
         SVAL       false
         VAL        false
       0.DUTY_CYCLE:
         OSVAL      false
         OVAL       false
         SVAL       false
         VAL        false
       0.DUTY_CYCLE_LEVEL:
         OSVAL      1.000000
         OVAL       1.000000
         SVAL       1.000000
         VAL        1.000000
       0.INSTALL_TEST:
         OSVAL      true
         OVAL       true
         SVAL       true
         VAL        true
       0.IP_ADDRESS:
         OSVAL      192.168.0.148
         OVAL       192.168.0.148
         SVAL       192.168.0.148
         VAL        192.168.0.148
       0.UNREACH:
         OSVAL      alive
         OVAL       0
         SVAL       alive
         VAL        false
Attributes:
   IODev      general.interfaces.homematic.ccu3
   alias      Hm-IP Accesspoint Obergeschoß
   ccureadingfilter .*
   ccureadingname 0.CARRIER_SENSE_LEVEL:carrier_sense_level;0.CONFIG_PENDING:config_pending;^0.DUTY_CYCLE$:duty_cycle;0.DUTY_CYCLE_LEVEL:duty_cycle_level;0.INSTALL_TEST:install_test;0.IP_ADDRESS:ip_address
   group      Zentralen & Gateways
   icon       hm_ccu@black
   room       Admin->Interfaces->Homematic
   sortby     2100
   stateFormat <table>
    <tr>
        <th style="text-align: left;">Duty Cycle</th>
        <td>[$name:duty_cycle_level:d2] %</td>
    </tr>
    <tr>
        <th style="text-align: left;">CSMA Level</th>
        <td>[$name:carrier_sense_level:d2] %</td>
    </tr>
    <tr>
        <th style="text-align: left;">Erreichbarkeit</th>
        <td>[$name:reachable_formatted]</td>
    </tr>
    <tr>
        <th style="text-align: left;">Lokale Adresse</th>
        <td>[$name:ip_address]</td>
    </tr>
</table>
   userReadings reachable_formatted:activity.+ {
    my $reachable = ::ReadingsVal($name, q(activity), undef);
    my @values = ($reachable)
        ?   ($reachable eq q(alive))
            ?   qw(green Erreichbar)
            :   qw(red Nicht erreichbar)
        :   qw(red Unbekannt);

    return sprintf q(<s