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.
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....
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 (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
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.
vermutlich hiermit
https://homematic-forum.de/forum/viewtopic.php?f=76&t=60150 (https://homematic-forum.de/forum/viewtopic.php?f=76&t=60150)
ist die platine denn nicht über den angepinnten thread zu finden?
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.
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.
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.
Was ist der Grund für diese vielen Funkmodule?
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.
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...)
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.
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...).
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.
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
Zitat von: fiedel am 12 April 2022, 09:45:37
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
Außer EQ-3 kommt niemand an das HmIP-Protokoll. Im GIT Repository (https://github.com/eq-3/occu) liegen entsprechend nur die Binärfiles vom HMServer. Die werden dann z.B. von Rasperrymatic übernommen.
Ich denke auch nicht, dass EQ-3 ein Interesse daran hat, das Protokoll offenzulegen. Schließlich sind die CCU Schnittstellen gut dokumentiert und werden auch von verschiedenen Smarthome Plattformen genutzt (ioBroker, OpenHab, ...). Keine Ahnung, warum man bei FHEM auf Reverse Engineering gesetzt und das Rad neu erfunden hat. War vor meiner FHEM Zeit. FHEM ging hier bisher also einen anderen Weg als die anderen großen Smarthome Plattformen.
Wenn man etwas reverse engineered bzw. nicht die dokumentierten Schnittstellen nutzt, läuft man halt in Gefahr, dass bei jeder Änderung seitens des Anbieters die eigene Lösung nicht mehr funktioniert.
Wie auch immer diese Dinge mal entstanden sind...
Jedenfalls stimmt m.E. die These nicht, dass ein "irrer Aufwand" erforderlich wäre, weder in finanzieller noch in "software-administrativer" Hinsicht.
Für mich waren (bereits schon vor dem Erscheinen von HM-IP) andere Gründe maßgebend, warum ich mich mit Alternativen beschäftigt habe - auch, wenn das im Ergebnis erst mal deutlich höherer Aufwand war wie nur die Installation einer (ggf. virtualisierten) CCU.
ZitatKeine Ahnung, warum man bei FHEM auf Reverse Engineering gesetzt und das Rad neu erfunden hat.
eventuell hätte eq3 nie das occu projekt begonnen, wenn es nicht zuvor reverse engeneering gegeben hätte.
ebenso hätte es die grandiose homebrew/asksin community nie gegeben.
Zitat von: zap am 12 April 2022, 09:58:07
Ich denke auch nicht, dass EQ-3 ein Interesse daran hat, das Protokoll offenzulegen. Schließlich sind die CCU Schnittstellen gut dokumentiert und werden auch von verschiedenen Smarthome Plattformen genutzt (ioBroker, OpenHab, ...). Keine Ahnung, warum man bei FHEM auf Reverse Engineering gesetzt und das Rad neu erfunden hat. War vor meiner FHEM Zeit. FHEM ging hier bisher also einen anderen Weg als die anderen großen Smarthome Plattformen.
Weil FHEM HM konnte, bevor überhaupt jemand daran gedacht hat, dass EQ-3 mal etwas offenlegen könnte. Und tatsächlich ist es in dem Rahmen auch sinnvoll. Es war vergleichsweise leicht, es zu machen und der Vorteil ist riesig. Man benötigt keinen "Zwischenwirt" (nur eine Zentrale), kann so viele IODevs verwenden, wie einem beliebt (bzw. ist der Rahmen nur schwer zu sprengen) und muss sich nicht mit der gräuseligen HM-CCU Software rumquälen (ok, das ist nun rein subjektiv aber es ist einfach vieles zu rudimentär). Für HM nutze ich noch immer NUR FHEM. Die Idee HM (ohne IP) auch auf eine CCU zu ziehen käme mir nie. Mit all den kleinen Zusatztools, die es mittlerweile gibt, schlägt FHEM die CCU um Längen.
Eigentlich kann EQ3 von der Offenlegung des Protokolls nur profitieren:
Wenn es gut ist, ist es auch offen sicher - wie z.B. Veracrypt.
Mehr Leute können HMIP einfacher einsetzen und die Nachfrage steigt - nicht zuletzt wegen der besseren Zukunftssicherheit bei offenem Protokoll.
AskSin ist keine Konkurrenz, sondern ein Segen für EQ3: Eine kostenlose Quelle für neue Ideen und man könnte sich gegenseitig unterstützen.
Aber vermutlich denke ich zu blauäugig... ;)
ZitatMit all den kleinen Zusatztools, die es mittlerweile gibt, schlägt FHEM die CCU um Längen.
Aus diesem Grund hatte ich mich damals für FHEM entschieden.
Anders wäre mein Projekt viel zu teuer geworden, und möglicherweise auch mit sonstiger SmartHome Lösungen bis heute nicht weiter als vor 7 Jahren.
FHEM ist für mich das Maß aller Dinge geworden, mit all dem, was ich schon alles implementiert habe.
Die Haustechnik bestand damals nur aus Stand alone Komponenten, die nicht miteinander kommunizieren konnten.
Erst als alles verknüpft wurde, konnte ich vieles erreichen, um viel an Energieaufwand einzusparen.
Gerade was das Zusammenspiel der Solaranlage mit der Heizung im Haus, Nebengebäude und dem Pool auf der einen Seite betrifft, als auch die PV-Anlage (derzeit noch ohne Batteriespeicher) für das Haus, das Nebengebäude, dem Pool und den gesamten Außenbereich.
Kleiner Projekte folgen noch, und dann folgen noch passende Visualisierungen.
Hierfür werde ich nun nicht mehr Homematic verwenden können, denn Homematic IP passt hier nicht mehr mit derzeitigem Stand der Technik in mein System.
Zitat von: marvin78 am 12 April 2022, 11:05:24
Weil FHEM HM konnte, bevor überhaupt jemand daran gedacht hat, dass EQ-3 mal etwas offenlegen könnte. Und tatsächlich ist es in dem Rahmen auch sinnvoll. Es war vergleichsweise leicht, es zu machen und der Vorteil ist riesig. Man benötigt keinen "Zwischenwirt" (nur eine Zentrale), kann so viele IODevs verwenden, wie einem beliebt (bzw. ist der Rahmen nur schwer zu sprengen) und muss sich nicht mit der gräuseligen HM-CCU Software rumquälen (ok, das ist nun rein subjektiv aber es ist einfach vieles zu rudimentär). Für HM nutze ich noch immer NUR FHEM. Die Idee HM (ohne IP) auch auf eine CCU zu ziehen käme mir nie. Mit all den kleinen Zusatztools, die es mittlerweile gibt, schlägt FHEM die CCU um Längen.
Nun, die Schnittstellen waren schon zu Zeiten der CCU1 offengelegt. Ich wusste nicht, dass FHEM bereits BidCos unterstützt hat, bevor EQ-3 Homematic auf den Markt brachte.
Zitat von: fiedel am 12 April 2022, 12:20:37
Eigentlich kann EQ3 von der Offenlegung des Protokolls nur profitieren:
das protokoll wird vermutlich ähnlich zu bidcos sein, empfangen lässt sich ja auch scheinbar alles.
das aktuelle problem ist doch wahrscheinlich "nur" der unbekannte default key zur entschlüsselung.
Zitat von: zap am 12 April 2022, 12:45:13
Nun, die Schnittstellen waren schon zu Zeiten der CCU1 offengelegt. Ich wusste nicht, dass FHEM bereits BidCos unterstützt hat, bevor EQ-3 Homematic auf den Markt brachte.
Die CCU1 gab es sehr lange. Soweit ich das im Kopf habe, waren die Schnittstellen zu Beginn nicht offengelegt und ich war ziemlich früh dabei. Selbst wenn es so war, schlägt das nicht die vielen guten Argumente für eine direkte Implementierung.
Zitat von: marvin78 am 12 April 2022, 15:53:23
Die CCU1 gab es sehr lange. Soweit ich das im Kopf habe, waren die Schnittstellen zu Beginn nicht offengelegt und ich war ziemlich früh dabei. Selbst wenn es so war, schlägt das nicht die vielen guten Argumente für eine direkte Implementierung.
Als Software Entwickler bekomme ich bei solchen "Lösungen" Schnappatmung und schlimmen Ausschlag ::)
Schnittstellen sind dazu da, genutzt zu werden. Aber gut, Zeitverschwendung, über Entscheidungen der Vergangenheit zu diskutieren.
Hier wird aber ein Element als Zwischenwirt ausgespart und nicht einfach nur eine Schnittstelle nicht genutzt. Als ebenfalls ursprünglich mal Entwickler halte ich das für einen guten Weg, da es die genannten Vorteile bringt. Deine Argumentation passt nur dann, wenn du die CCU nicht weg lassen könntest. Es entfällt ein Teil, der gewartet und am Leben gehalten werden muss. Das ist durchaus sehr wünschenswert.
Ich denke, dass man trotzdem mal ein Blueprint für die Zukunft machen sollte: Wie kann man sein HM-System in die Zukunft retten, wenn eQ3 irgendwann HM komplett abverkauft hat?
LG
pah