Homematic IP Geräte Erweiterung

Begonnen von Burny4600, 09 April 2022, 15:49:34

Vorheriges Thema - Nächstes Thema

Burny4600

Bisher habe ich eine Menge an den Homematic Geräten im Einsatz.
Da es jetzt vermehrt für Erweiterungen nur mehr Homematic IP Geräte gibt, muss ich mir etwas einfallen lassen.

list VCCU
Internals:
   CFGFN      /media/hdd/fhem/mycfg/HM/hm_rasp01.cfg
   DEF        F12347
   FUUID      5c45b04c-f33f-f4d2-4334-8937b207a433d26e
   HmUART_AB_GTO_MSGCNT 502
   HmUART_AB_GTO_RAWMSG 0500004BFF8002F123475D015E00
   HmUART_AB_GTO_RSSI -75
   HmUART_AB_GTO_TIME 2022-04-09 15:45:05
   HmUART_EG_MSGCNT 546
   HmUART_EG_RAWMSG 0500004BFF8002F123475D015E00
   HmUART_EG_RSSI -75
   HmUART_EG_TIME 2022-04-09 15:45:05
   HmUART_OG1_MSGCNT 590
   HmUART_OG1_RAWMSG 0500004A8A8002F123474C1E9000
   HmUART_OG1_RSSI -74
   HmUART_OG1_TIME 2022-04-09 15:45:58
   HmUART_OG2_MSGCNT 224
   HmUART_OG2_RAWMSG 0500003DFF8002F123475D015E00
   HmUART_OG2_RSSI -61
   HmUART_OG2_TIME 2022-04-09 15:45:05
   HmUART_Test_MSGCNT 531
   HmUART_Test_RAWMSG 050000498A8002F123474C1E9000
   HmUART_Test_RSSI -73
   HmUART_Test_TIME 2022-04-09 15:45:58
   IODev      HmUART_AB_FR
   LASTInputDev HmUART_Test
   MSGCNT     2393
   NAME       VCCU
   NOTIFYDEV  global
   NR         4978
   NTFY_ORDER 48-VCCU
   STATE      HmUART_AB_FR:ok,HmUART_AB_GTO:ok,HmUART_EG:ok,HmUART_OG1:ok,HmUART_OG2:ok,HmUART_Test:ok
   TYPE       CUL_HM
   assignedIOs HmUART_AB_FR,HmUART_AB_GTO,HmUART_EG,HmUART_OG1,HmUART_OG2,HmUART_Test
   channel_01 VCCU_Btn1
   lastMsg    No:8A - t:02 s:F12347 d:4C1E90 00
   protLastRcv 2022-04-09 15:45:58
   protRcv    803 last_at:2022-04-09 15:45:58
   protRcvB   59 last_at:2022-04-09 14:49:20
   rssi_at_HmUART_AB_GTO cnt:502 min:-77 max:-50 avg:-59.01 lst:-75
   rssi_at_HmUART_EG cnt:546 min:-92 max:-71 avg:-84.44 lst:-75
   rssi_at_HmUART_OG1 cnt:590 min:-74 max:-50 avg:-61 lst:-74
   rssi_at_HmUART_OG2 cnt:224 min:-85 max:-55 avg:-59.29 lst:-61
   rssi_at_HmUART_Test cnt:531 min:-90 max:-48 avg:-62.65 lst:-73
   READINGS:
     2022-04-09 15:45:58   CommandAccepted yes
     2022-04-09 12:07:38   IODev           HmUART_AB_FR
     2022-04-09 15:43:19   IOopen          6
     2022-04-09 12:04:24   aesReqTo        EG_SL_HZG_RT
     2022-04-04 17:33:58   cfgState        ok
     2022-04-09 13:14:13   hmPair          timeout
     2022-04-09 15:43:19   state           HmUART_AB_FR:ok,HmUART_AB_GTO:ok,HmUART_EG:ok,HmUART_OG1:ok,HmUART_OG2:ok,HmUART_Test:ok
   helper:
     HM_CMDNR   138
     PONtest    1
     lastMsgTm  1649511958.85324
     mId        FFF0
     peerFriend -
     peerOpt    -:virtual
     regLst     
     rxType     1
     supp_Pair_Rep 0
     ack:
     cmds:
       TmplKey    :no:1649498861.64647
       TmplTs     1649498861.64647
       cmdKey     0:1:1::VCCU:FFF0:00:
       cmdLst:
         assignIO   -IO- [({set}|unset)]
         clear      [(readings|rssi|msgEvents|attack|{msgErrors}|unknownDev)]
         defIgnUnknown noArg
         hmPairForSec [-sec-]
         hmPairSerial -serial-
         tplSet_0   -tplChan-
         update     noArg
         virtual    [(1..50;1|{1})]
       lst:
         condition  slider,0,1,255
         peer       
         peerOpt   
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         listDevice noArg
         param      -param-
     expert:
       def        1
       det        0
       raw        0
       tpl        0
     io:
       nextSend   1649511958.89189
       vccu       VCCU
       ioList:
         HmUART_AB_FR
         HmUART_AB_GTO
         HmUART_EG
         HmUART_OG1
         HmUART_OG2
         HmUART_Test
       prefIO:
     mRssi:
       mNo        8A
       io:
         HmUART_AB_GTO:
           -75
         HmUART_EG:
           -75
         HmUART_OG1:
           -74
           -74
         HmUART_OG2:
           -61
         HmUART_Test:
           -73
           -73
     peerIDsH:
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       vrt        1
     rssi:
       at_HmUART_AB_GTO:
         avg        -59.0179282868526
         cnt        502
         lst        -75
         max        -50
         min        -77
       at_HmUART_EG:
         avg        -84.4432234432234
         cnt        546
         lst        -75
         max        -71
         min        -92
       at_HmUART_OG1:
         avg        -61.0033898305085
         cnt        590
         lst        -74
         max        -50
         min        -74
       at_HmUART_OG2:
         avg        -59.2901785714286
         cnt        224
         lst        -61
         max        -55
         min        -85
       at_HmUART_Test:
         avg        -62.6591337099812
         cnt        531
         lst        -73
         max        -48
         min        -90
     shadowReg:
     tmpl:
Attributes:
   IOList     HmUART_AB_FR,HmUART_AB_GTO,HmUART_EG,HmUART_OG1,HmUART_OG2,HmUART_Test
   IOgrp      VCCU
   aesCommReq 0
   alias      HomeMatic Virtuelle CCU
   event-on-change-reading .*
   group      .HomeMatic VCCU
   hmKey      01:e1fa95c5613ea3c257a6862a2fdc6bf9
   hmKey2     02:eb6e444f34df0e509c3a82a0a079772c
   hmKey3     03:ee955645ccc18dc0ebb5a137bf7c9e70
   icon       hm_ccu
   model      CCU-FHEM
   room       _HM,_Kontaktsensoren,_RxTx
   subType    virtual
   verbose    0
   webCmd     virtual:update


Was ich aber verhindern möchte, ist einen zusätzlichen Raspberry oder anderes Gerät inklusive Funkmodule zu installieren.
Zumindest habe ich es so verstanden, beim Studium der vielen Threads.
LG Chris

Raspberry Pi 2-5, Bullseye Lite, Bookworm Lite
Schnittstellen: 1-Wire, FHEM2FEHEM, HM-MOD-UART, LAN, Modbus, MQTT, nanoCUL, RFXtrx433E, SIGNALduino, ser2net
Devices: APC, Eastron, FS20, IT, Homematic, MQTT, PV-(DEYE, EPEVER, FRONIUS), Resol-VBUS, S.USV, TEK603, WMR200, YouLess

DerBodo

Hi Burny,

weiterhelfen kann ich dir dabei leider nicht, stehe aber vor einem ähnlichen Problem.
Um eine Software CCU (piVCCU, Debmatic etc.) kommen wir wohl nicht drum rum, Anbindung läuft dann über HMCCU (parallel zur VCCU via CUL_HM wenn wir nicht alles neu einrichten/anlegen wollen).

Bei mir wäre jetzt noch das Problem, dass bei mir alles in VM's auf nem ESXI läuft.
Ein entsprechendes Funkmodul welches nur für HMIP zuständig ist müsste dann auch über Ethernet angebunden werden.
Ob da die Aktuellen HMUART Devices Funktionieren konnte ich leider noch nicht rausfinden....


moskito

Hallo Mitstreiter,

um etwas zukunftssicher unterwegs zu sein, habe ich mich letztens mit der Problematik auseinandergesetzt, so lange noch kein Leidensdruck besteht und man das in Ruhe ausprobieren kann.
Ich  habe mir bei ELV diesen Stick geholt: https://de.elv.com/elv-homematic-ip-arr-bausatz-rf-usb-stick-fuer-alternative-steuerungsplattformen-hmip-rfusb-fuer-smart-home-hausautomation-152306?fs=4036625683&c=691 und noch einen HM-IP Fensterkontakt dazu.
Da mein FHEM auch schon virtualisiert ist, habe ich dann eine virtuelle Maschine mit Raspberrymatic aufgesetzt und diese über HMCCU eingebunden.
Funktionierte relativ reibungslos und läuft parallel zum HM-CFG-USB Stick mit der "alten" Homematicwelt.
Man mus halt bei HMCCU ein wenig umdenken und hat prinzipiell wieder eine Fehlerquelle mehr (Raspberrymatic), aber ohne gibt´s halt kein HM-IP.

Gruß
Danny
FHEM auf Intel NUC/Proxmox & Debian 12 + HM-CFG-USB + zigbee2mqtt + Zwave + Enocean

DerBodo

Hi Danny,

Ich würde gerne um einen USB Stick herumkommen und etwas Ähnliches wie die HMUART GW's nutzen.
Das macht die Platzierung im Haus bedeutend einfacher.

Ich denke mal Burny geht es ähnlich. Er hat je bereits eine Ganze Menge an HMUARTs einfebunden.


frank

vermutlich hiermit
https://homematic-forum.de/forum/viewtopic.php?f=76&t=60150

ist die platine denn nicht über den angepinnten thread zu finden?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Burny4600

#5
Ein weiteres großes Problem sehe ich aber da auf mich zukommen.
Wenn ich meinem Haustechnikbereich mancherorts mit Homematic IP erweitern möchte, brauche ich zusätzlich wieder eine Menge Funkmodule. Und nicht nur das, soweit ich das richtig verstanden habe.
Wobei eigentlich die vorhanden UARTs Homematic IP unterstützen würden.

Auf meiner Hauptinstanz ist ein HM-MOD-UART. Alle anderen HM-MOD-UART sind via ser2net mit der Hauptinstanz verbunden.

Die Hauptinstanz bedient alle im Umfeld vorhanden HM Geräte.
devices using VCCU
current IO / preferred
  HmUART_AB_FR / --- AB_BKTR_BW
  HmUART_AB_FR / --- AB_FR_AAM
  HmUART_AB_FR / --- AB_FR_AD
  HmUART_AB_FR / --- AB_FR_BL_RGB
  HmUART_AB_FR / --- AB_GO_RM
  HmUART_AB_FR / --- AB_GO_RM_TEAMDEV
  HmUART_AB_FR / --- AB_MB_PS
  HmUART_AB_FR / --- AB_SA_NT
  HmUART_AB_FR / --- AB_SG_BLWSBWS
  HmUART_AB_FR / --- AB_SG_BWEH12
  HmUART_AB_FR / --- AB_SG_BWEH56
  HmUART_AB_FR / --- AB_VG_BW
  HmUART_AB_FR / --- EG_STH_AAM
  HmUART_AB_FR / --- HM_6A9533
  HmUART_AB_FR / --- OG1_VR_AAM
  HmUART_AB_FR / --- UESF1_AB_FR
  HmUART_AB_FR / --- UEST1_AB_FR
  HmUART_AB_FR / --- UEST1_AB_SA
  HmUART_AB_FR / --- UEST2_AB_GAO
  HmUART_AB_FR / --- VCCU
  HmUART_AB_GTO / --- EG_VR_RM
  HmUART_AB_GTO / --- EG_WZ_RM
  HmUART_AB_GTO / --- HM_6A8CB3
  HmUART_AB_GTO / --- OG2_BU1_HZG_RT
  HmUART_AB_GTO / --- OG2_BU2_HZG_RT2
  HmUART_AB_GTO / --- OG2_BU2_HZG_TC
  HmUART_AB_GTO / --- UESF1_OG1_BA
  HmUART_AB_GTO / --- UESF1_OG2_BUE1_N
  HmUART_AB_GTO / --- UESF2_OG2_BUE1_N
  HmUART_AB_GTO / --- UESF3_OG2_BUE1_N
  HmUART_AB_GTO / --- UESF3_OG2_BUE2_W
  HmUART_EG / --- EG_BA_HZG_RT
  HmUART_EG / --- EG_RM_TEAMDEV
  HmUART_EG / --- EG_SL_HZG_RT
  HmUART_EG / --- EG_SL_HZG_TC
  HmUART_EG / --- EG_SL_RM
  HmUART_EG / --- EG_WC_HZG_RT
  HmUART_EG / --- EG_WC_HZG_TC
  HmUART_EG / --- EG_WI_HZG_RT
  HmUART_EG / --- EG_WI_HZG_TC
  HmUART_EG / --- UESF1_EG_SL
  HmUART_EG / --- UESF1_EG_WI
  HmUART_EG / --- UESF2_EG_SL
  HmUART_EG / --- UEST1_EG_BA
  HmUART_EG / --- UEST1_EG_STH
  HmUART_OG1 / --- EG_KU_HZG_RT
  HmUART_OG1 / --- EG_STH_HZG_RT
  HmUART_OG1 / --- EG_STH_T1_FB
  HmUART_OG1 / --- EG_STH_T1_VGT
  HmUART_OG1 / --- EG_STH_ZS_T1VGF
  HmUART_OG1 / --- EG_WZ_HZG_TC
  HmUART_OG1 / --- OG1_KI_HZG_RT
  HmUART_OG1 / --- OG1_KI_HZG_TC
  HmUART_OG1 / --- OG1_KU_HZG_TC
  HmUART_OG1 / --- OG1_KU_WA_OAFGO
  HmUART_OG1 / --- OG1_RM_TEAMDEV
  HmUART_OG1 / --- OG1_SL_BLO
  HmUART_OG1 / --- OG1_SL_FB1
  HmUART_OG1 / --- OG1_SL_FB2
  HmUART_OG1 / --- OG1_STH_HZG_RT
  HmUART_OG1 / --- OG1_STH_HZG_TC
  HmUART_OG1 / --- OG1_STH_RM
  HmUART_OG1 / --- OG1_WC_HZG_RT
  HmUART_OG1 / --- OG1_WC_HZG_TC
  HmUART_OG1 / --- STH_RM_TEAMDEV
  HmUART_OG1 / --- UESF1_EG_STH
  HmUART_OG1 / --- UESF1_OG1_KI
  HmUART_OG1 / --- UESF1_OG1_SL
  HmUART_OG1 / --- UESF1_OG2_BUE2_W
  HmUART_OG1 / --- UESF2_OG1_SL
  HmUART_OG1 / --- UESF3_OG1_STH
  HmUART_OG1 / --- UESF5_OG2_STH
  HmUART_OG1 / --- UEST1_EG_KUE
  HmUART_OG1 / --- UEST1_OG1_KUE
  HmUART_OG2 / --- AB_FR_RM
  HmUART_OG2 / --- AB_SG_BWEH34
  HmUART_OG2 / --- AB_WST_RS
  HmUART_OG2 / --- EG_KUE_RM
  HmUART_OG2 / --- EG_KU_HZG_TC
  HmUART_OG2 / --- EG_WR_RM
  HmUART_OG2 / --- OG1_KI_RM
  HmUART_OG2 / --- OG1_KUE_RM
  HmUART_OG2 / --- OG1_KU_FS1_OAI
  HmUART_OG2 / --- OG1_KU_FS2_OAI
  HmUART_OG2 / --- OG1_KU_HZG_RT
  HmUART_OG2 / --- OG1_SL_FB3
  HmUART_OG2 / --- OG1_SL_RM
  HmUART_OG2 / --- OG1_VR_RM
  HmUART_OG2 / --- OG1_WZ_HZG_TC
  HmUART_OG2 / --- OG1_WZ_RM
  HmUART_OG2 / --- OG2_B1_KG
  HmUART_OG2 / --- OG2_BU1_AAM
  HmUART_OG2 / --- OG2_BU1_HZG_TC
  HmUART_OG2 / --- OG2_BU1_RM
  HmUART_OG2 / --- OG2_BU2_HZG_RT1
  HmUART_OG2 / --- OG2_BU2_RM
  HmUART_OG2 / --- OG2_DB_RM
  HmUART_OG2 / --- OG2_EDV_RM
  HmUART_OG2 / --- OG2_RM_TEAMDEV
  HmUART_OG2 / --- OG2_VR_RM
  HmUART_OG2 / --- OG2_VR_STI
  HmUART_OG2 / --- OG2_WC_HZG_RT
  HmUART_OG2 / --- OG2_WC_HZG_TC
  HmUART_OG2 / --- UESF1_OG1_KUE
  HmUART_OG2 / --- UESF1_OG1_WC
  HmUART_OG2 / --- UESF1_OG2_BUE2_N
  HmUART_OG2 / --- UESF1_OG2_DB
  HmUART_OG2 / --- UESF1_OG2_DBN
  HmUART_OG2 / --- UESF2_EG_STH
  HmUART_OG2 / --- UESF2_OG2_BUE2_N
  HmUART_OG2 / --- UESF2_OG2_BUE2_W
  HmUART_OG2 / --- UESF2_OG2_DBN
  HmUART_OG2 / --- UESF3_OG2_DBN
  HmUART_OG2 / --- UESF4_OG1_STH
  HmUART_OG2 / --- UEST1_OG2_EDV
  HmUART_Test / --- AB_GAO_FS1_SSPPWTI
  HmUART_Test / --- AB_SG_BLGOBWS
  HmUART_Test / --- EG_BA_HZG_TC
  HmUART_Test / --- EG_KUE_AAM
  HmUART_Test / --- EG_WZ_HZG_RT
  HmUART_Test / --- OG1_BA_HZG_TC
  HmUART_Test / --- OG1_SL_HZG_RT
  HmUART_Test / --- OG1_SL_HZG_TC
  HmUART_Test / --- OG1_WZ_BL_RGB
  HmUART_Test / --- OG1_WZ_BL_VIO
  HmUART_Test / --- OG1_WZ_HZG_RT
  HmUART_Test / --- UESF1_AB_GAO
  HmUART_Test / --- UESF1_EG_BA
  HmUART_Test / --- UESF1_EG_KUE
  HmUART_Test / --- UESF1_EG_WC
  HmUART_Test / --- UESF1_EG_WZ
  HmUART_Test / --- UESF1_OG1_WZ
  HmUART_Test / --- UESF2_AB_GAO
  HmUART_Test / --- UESF2_EG_WZ
  HmUART_Test / --- UESF2_OG1_WZ
  HmUART_Test / --- UEST1_AB_GAO
  HmUART_Test / --- UEST1_AB_GTW
  HmUART_Test / --- UEST2_AB_GAW


Ich habe damals auf Homematic gesetzt, weil ich dachte, dass dieses System für längere Zeit erhalten bleibt. Nun stirbt es schön langsam aus.
Jedenfalls muss ich mir hierfür eine passende Lösung erarbeiten, die nicht wieder eine Menge an zusätzliche Komponenten und Geld benötigen.

Der Stromverbrauch des eingesetzten FHEMs ist mir egal.
Die gesamte Haustechnik wird mittels 24V Ringleitung, die durch die Verteiler führt, versorgt.
Die Stromversorgung wird nur aus Solarstrom mit Batterieeinheit zur Verfügung gestellt. Angeschlossen sind an dieser Stromversorgung auch eine Notbeleuchtung mit 12V und 230V sowie die Zutrittskontrollen, Videoüberwachungen und der ganze Poolbereich inklusive Poolpumpen und Beleuchtung.

Ich werde mir andere System noch ansehen, da auch nanoCULs 433MHz und 868MHz in Verwendung habe. Wenn die Geräte nicht miteinander gepeert und gepairt sein müssen, spielt es grundsätzlich keine Rolle, was ich als Systemerweiterung einsetze.
LG Chris

Raspberry Pi 2-5, Bullseye Lite, Bookworm Lite
Schnittstellen: 1-Wire, FHEM2FEHEM, HM-MOD-UART, LAN, Modbus, MQTT, nanoCUL, RFXtrx433E, SIGNALduino, ser2net
Devices: APC, Eastron, FS20, IT, Homematic, MQTT, PV-(DEYE, EPEVER, FRONIUS), Resol-VBUS, S.USV, TEK603, WMR200, YouLess

Otto123

#6
138 Funkmodule HM-MOD-RPI-PCB - Respekt! Ich sollte genauer hinschauen und nicht nur die Zeilen zählen  :o
Wenn ich es richtig verstehe könntest Du mit der von Frank erwähnten Platine HB-RF-ETH alle Module nach und nach  HM IP fähig machen und mit einer zentralen piVCCU / debmatic (oder auch mehrere falls HMCCU mehrere einbinden kann?) verbinden.

Damit kannst Du alle Funkmodule weiterverwenden, um HM IP erweitern und brauchst "nur" jeweils eine Platine HB-RF-ETH dazu.

Ansonsten klingt es für die Erweiterung von der Struktur her eher nach einem vermaschten Funksystem wie Zigbee oder so. Aber ich habe keine Ahnung wie viele Komponenten da überhaupt in einem Netzwerk sein können. Bei Homematic lag ja wohl die Begrenzung immer eher bei der Leistungsfähigkeit der Zentrale (oder IO?) und ich meine mal was von 1000 Geräten gelesen zu haben.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

frank

Zitat138 Funkmodule HM-MOD-RPI-PCB - Respekt!
ich erkenne nur 6.  :)
aber auch diese infrastruktur lässt sich vermutlich nur schwer über ccu/hmccu umsetzen.


ZitatWenn ich es richtig verstehe könntest Du mit der von Frank erwähnten Platine HB-RF-ETH alle Module nach und nach  HM IP fähig machen und mit einer zentralen piVCCU / debmatic (oder auch mehrere falls HMCCU mehrere einbinden kann?) verbinden.
leider nur immer ein io pro ccu.
ZitatBekannte Einschränkungen:
    An einer CCU Installation kann immer nur ein Funkmodul angebunden werden, dabei ist es egal, ob der Anschluss per GPIO Header, per USB oder eben jetzt per Netzwerk erfolgt

zusätzliche io, so wie ich es verstehe, können aber immer nur 1 funkprotokol, was wiederum abhängig ist vom "zentralen" io.
1. wenn das zentrale io ein HM-MOD-RPI-PCB ist, kann man nur zusätzliche bidcos io mit hilfe von HM-LGW-O-TW-W-EU anbinden.
2. wenn das zentrale io ein RPI-RF-MOD oder HmIP-RFUSB ist, kann man zusätzliche hmip io mit hilfe von HmIP-HAP anbinden. fraglich bleibt, ob dann auch gleichzeitig zusätzliche HM-LGW-O-TW-W-EU io funktionieren.
3. die anzahl zusätzlicher io ist wohl in jedem fall begrenzt.

alles in allem scheinbar sehr kompliziert, eventuell über mehrere ccu.
vermutlich am einfachsten ist wahrscheinlich ein zusätzliches hmip/ccu system und alles bisherige lassen wie es ist.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

zap

Was ist der Grund für diese vielen Funkmodule?
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

Burny4600

ZitatWas ist der Grund für diese vielen Funkmodule?
Um das gesamte Objekt abdecken zu können. Mit einem einzigen Funkmodul ist es nicht möglich, eine entsprechend sichere Abdeckung zu gewährleisten.
Exponierte Garagen und Gebäudeteile, mehrere Stockwerke usw.
LG Chris

Raspberry Pi 2-5, Bullseye Lite, Bookworm Lite
Schnittstellen: 1-Wire, FHEM2FEHEM, HM-MOD-UART, LAN, Modbus, MQTT, nanoCUL, RFXtrx433E, SIGNALduino, ser2net
Devices: APC, Eastron, FS20, IT, Homematic, MQTT, PV-(DEYE, EPEVER, FRONIUS), Resol-VBUS, S.USV, TEK603, WMR200, YouLess

Beta-User

Zitat von: Otto123 am 11 April 2022, 12:13:16
Ansonsten klingt es für die Erweiterung von der Struktur her eher nach einem vermaschten Funksystem wie Zigbee oder so.
Sehe ich ähnlich, woebei HM-IP auch Mesh-fähig wäre, allerdings ist da nicht jedes Gerät ein "Repeater".

Zitat von: Burny4600 am 11 April 2022, 09:53:41
Ich werde mir andere System noch ansehen, da auch nanoCULs 433MHz und 868MHz in Verwendung habe. Wenn die Geräte nicht miteinander gepeert und gepairt sein müssen, spielt es grundsätzlich keine Rolle, was ich als Systemerweiterung einsetze.
Z-Wave kann pro IO (vermesht) ca. 230 Geräte haben, bei max. 4 "hops" (= ca. 200m Reichweite).
https://www.reddit.com/r/zwave/comments/5r8ndg/size_limit_for_reliable_zwave_network/

Bei ZigBee ist eine Antwort wohl etwas schwieriger zu finden, aber auch da scheinen ähnliche Größenordnungen ohne weiteres möglich zu sein (vorausgesetzt, man hat einen leistungsfähigen "Coordinator" im Einsatz, was aber heutzutage nicht das Problem sein sollte...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Burny4600

#11
Z-Wave sieht nicht schlecht aus, ist aber für mich mit dem aktuellen Status kein Thema.
Es sind nur mehr ein paar wenige Geräteanbindungen, die per Funk ergänzt werden, und die sonstigen Anbindungen sind per IOs verdrahtet fertigzustellen.
Da werde ich mich eher mit MQTT weiter beschäftigen, oder bei Komponenten, die via nanoCULs arbeiten.

Auf Homematic IP werde ich mich nicht mehr einlassen.
Den irrtümlich gekauften HmIP-FSM Aktor werde ich wieder hergeben.

Hoffentlich halten die im Einsatz vorhanden Homematic Geräte eine lange Zeit.
Bei den Rauchmeldern wird es in ca. 8 Jahren zu einem Problem kommen, wenn die Batterien verbracht sind. Dann wird sich zeigen, ob ein Batterietausch möglich ist oder ein Systemwechsel notwendig wird, der erhebliche Kosten verursachen wird.
Da hab ich wohl aufs falsche Pferd gesetzt.

LG Chris

Raspberry Pi 2-5, Bullseye Lite, Bookworm Lite
Schnittstellen: 1-Wire, FHEM2FEHEM, HM-MOD-UART, LAN, Modbus, MQTT, nanoCUL, RFXtrx433E, SIGNALduino, ser2net
Devices: APC, Eastron, FS20, IT, Homematic, MQTT, PV-(DEYE, EPEVER, FRONIUS), Resol-VBUS, S.USV, TEK603, WMR200, YouLess

Beta-User

#12
Na ja, kein System wird "ewig" verfügbar sein, und auch bei Z-Wave bzw. ZigBee gibt es unterschiedliche "Generationen". Man ist damit halt nicht von einem bestimmten Hersteller abhängig.

Was "Batterietausch" und Rauchmelder angeht, solltest du den Gedanken wohl direkt ad acta legen: Die Dinger sind nicht für Batterietausch gemacht und danach dem Vernehmen nach auch nicht mehr sicher verwendbar.

Es ist sicher eine gute Idee, alles zu verkabeln (habe ich z.B. im Keller auch auf MySensors/RS485-Basis gemacht), aber für Mesh-Systeme ist es andererseits erforderlich (oder zumindest dringend zu empfehlen), genügend dauerbestromte "repeater" vorzusehen. ZigBee funktioniert z.B. hier erst zufriedenstellend (bis "gut"), seit ich ein paar mehr "hinter dem Schalter"-Aktoren verteilt habe... Nur mit Batterie-Geräten (wie z.B. Rauchmeldern) wirst du damit ziemlich sicher nicht glücklich, selbst wenn die Preise deutlich erschwinglicher sind als HM (-IP) und die Dinger auch optisch mehr hermachen...

Nachtrag:
- "MQTT" ist ein Protokoll, kein bestimmtes System an sich.
- Mit nur nanoCUL wirst du vermutlich nicht mehr glücklich, die Zeiten sind überwiegend vorbei, in denen dafür bidirektionale Systeme entwickelt wurden (ich habe für Z-Wave auch experimentell einen Maple-CUN im Einsatz; das geht schon, aber.... na ja, ich bin froh um das "reguläre" USB-Dongle für <30 Euro...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

zap

Zitat von: Beta-User am 11 April 2022, 16:15:36
Sehe ich ähnlich, woebei HM-IP auch Mesh-fähig wäre, allerdings ist da nicht jedes Gerät ein "Repeater".

HmIP routet, kleiner Unterschied. Noch nicht alle Geräte können das, aber immer mehr.
Und man könnte noch LAN Gateways einsetzen.
2xCCU3 mit ca. 100 Aktoren, Sensoren
Entwicklung: FHEM auf Proxmox Debian VM
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: HMCCU, (Fully, AndroidDB)

fiedel

Das ist doch alles total unbefriedigend. Die neuen Geräte sind nicht schlecht, aber ich werde sie nicht kaufen solange dieser irre Aufwand erforderlich ist.

Wie kommen denn Alexander Reinert und Jens Maus (debmatic / raspberrymatic) an das HMIP- Protokoll?
Kann denn der FHEM- Verein da nichts machen? Prof. Redeker (EQ3/ELV) müsste doch Interesse daran haben, dass jede gößere Smart Home- Plattform dieses Protokoll direkt hat.
Um so beliebter wären die Komponenten.

Gruß
Frank

FeatureLevel: 6.1 auf Wyse N03D ; Deb. 11 ; Perl: v5.14.2 ; IO: HM-MOD-RPI-PCB + VCCU|CUL 868 V 1.66|LinkUSBi |TEK603
HM: SEC-SCO|SCI-3-FM|LC-SW4-PCB|ES-PMSW1-PL|RC-4-2|SEN-MDIR-O|SEC-WDS-2
CUL: HMS100TF|FS20 S4A-2 ; OWDevice: DS18S20|DS2401|DS2406|DS2423