Beratung und Grundsatzfragen zum Hardwarekauf

Begonnen von FHEM_ASB, 02 Dezember 2018, 19:12:49

Vorheriges Thema - Nächstes Thema

FHEM_ASB

Hallo Zusammen,
mein Name ist Roland und ich bin ein (mittlerweile gestresster) QIVICON bzw. Telekom SmartHome User. Die Installation läuft knapp zwei Jahre und war mein Einstieg in das Thema Hausautomation. Anfangs recht zufrieden stört mich nun aber, das die Qivicon Programmierer darüber entscheiden, was ich nutzen darf und was nicht. Z.B. Würde ich gerne mehr auf Homematic IP setzen, kann die Komponenten aber nicht anlernen, weil nicht unterstützt. Und die Aussagen, wann etwas kommt oder nicht sind allesamt wertlos.

Aktuell besitze ich:
- Homematic und Homematic IP Komponenten zur Haussicherung (Bewegungsmeldern, Fenstersensoren, Handsender)
- einen HMIP Accesspoint
- Logitech Circle 2 Kameras
- HUE Lampen
- Alexa
- Bose

Kommen soll noch:
- HMIP Fußbodenheizungssteuerung und Wandthermostate für alle Räume
- Rolladensteuerung
- Wetterstation
- Steuerung für Gartenbewässerung

Ich beabsichtige einen Raspberry einzusetzen und benötige in der ersten Ausbaustufe zwingend die Möglichkeit für Homematic UND Homematic IP Komponenten. Aber egal wieviel ich lese, ich komme nicht durch den Dschungel an Infos. Immer wenn ich denke, jetzt weiß ich es, kommt eine irgendeine Einschränkung oder ich bin nicht sicher, ob beides auf einem Raspberry läuft und auch kompatibel ist.

Was genau benötige ich zusätzlich zum Raspberry um beides zu nutzen? Einen CUL für HM und einen für HMiP? Oder einen Software CUL? Oder brauche ich 2 Raspberrys? Kann ich den Accesspoint für irgendwas nutzen?

Sorry für soviel Input und Vielen Dank für eure Inspirationen :-)

Neuhier

Für Raspi gibts einen HM-Aufsatz.
ZigBee ist als Stick mit zigbee2mqtt machbar - für z.B. Osram, HUE, Xiaomi/ Aqara....

Von HMIP halte ich nix, ist deren Server down, sind Deine Komponenten nicht erreichbar.
Kann sein, daß da mittlerweile die Freaks was haben, ist aber nicht mein Interessenfeld.


MadMax-FHEM

#2
Für HMIP brauchst du unbedingt eine CCU!

Es gibt die Möglichkeit auf Basis eines PI mit dem Aufsteckmodul für den Bausatz "Charly" von ELV eine CCU3 selbst zu "bauen" und darauf dann theoretisch auch fhem laufen zu lassen.

Ist aber wohl u.U. nicht so einfach (also fhem auch noch drauf zu packen).

Gibt einen releativ neuen Thread zu dem Thema...
...irgendwas wie: fhem auf CCU3...

Ansonsten gibt es die auf jeden Fall funktionierende Möglichkeit: CCU2 oder CCU3 (wahrschinlich besser gleich das zu machen) und dann per HMCCU in fhem einbinden (musst du auch tun, wenn fhem auf der CCU läuft). Also 2 verschiedene Systeme: CCU2/CCU3 (selbstbau) und fhem.

Die HomeMatic Komponenten (OHNE IP) könntest du auch direkt an fhem anbinden...
...aber ich würde da nicht mischen: also HMohneIP an fhem und HMmitIP dann an CCU und per HMCCU in fhem...
...sondern gleich alles an die CCU und dann per HMCCU-Modul in fhem.

Soweit mir bekannt läuft HomeMatic IP mit CCU auch lokal ohne Internet und Cloud...
...aber da vielleicht noch mal im Internet recherieren (habe kein HomeMatic IP).

Ich lese grad (noch mal): du hast ja schon eine HMIP-Zentrale!? CCU2/CCU3? Die dann "einfach" per HMCCU-Modul in fhem einbinden...

TIPP: lass die Finger von einem CUL für HomeMatic!!

Für Zigbee gibt es neben der erwähnten Variante auch noch das RaspBee Modul von Dresden Elektronik und das dann als HUE-Bridge einbinden.
Mache ich so, habe aber nur HUE...
...und ich habe einen extra PI dafür (weiß aber nicht, ob das ein MUSS ist).

Wenn du auch bereits eine HUE-Bridge hast, dann kannst du die nat. auch gleich direkt mittels HUE-Bridge-Modul einbinden...

Für Alexa gibt es (mind.) 2 Möglichkeiten: ha-bridge bzw. alexa-fhem. Damit sind dann praktisch alle in fhem vorhandenen und schaltbaren Geräte per Alexa steuerbar...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

FHEM_ASB

Vielen Dank. Mir war nicht klar, das HMIP ausschließlich mit einer CCU betrieben werden kann. Dann verstehe ich auch, warum viele auf HM ohne IP setzen. Ich habe leider keine VCu, sondern den Access Point. Der dürfte dann wohl nicht ausreichen.

MadMax-FHEM

Ich kenne jetzt den "Accesspoint" nicht.
Habe aber eben mal bei ELV geschaut: wird wohl nicht klappen diesen einzubinden.

Und es ist damit wohl/vermutlich so, wie Neuhier geschrieben hat: ohne Cloud (und die war schon immer wieder mal einige Zeit [Stunden/Tage] weg) geht dann wohl nicht mehr viel...

Aber wenn du weiterhin eher HM-IP einsetzen willst und auch fhem, dann wirst du wohl an einer CCU (evtl. selbstbau "Charly" https://www.elv.de/homematic-funk-modulplatine-fuer-raspberry-pi-3-rpi-rf-mod-komplettbausatz.html bzw. https://www.elv.de/elv-smart-home-zentrale-charly-starter-set-bausatz.html) vorbei kommen.

Hinweis: vccu ist hat NICHTS mit CCU zu tun!

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

@Joachim:Bist du sicher, dass nur der Charly für eine CCU funktioniert? Nach meinem Kennstnisstand sollte eine (ggf. z.B. mit piVCCU) virtualisierte CCU auf demselben Rechner auch mit dem "alten" PI-PCB laufen, ohne dass man wesentliche Nachteile hat. Die Behauptung von eQ-3, das Ding habe eine bessere Funkleistung wurde jedenfalls neulich mal von jemandem getestet und hat die Stichprobe nicht bestanden ;) . (eQ-3 halt, wage ich mal zu behaupten...) (und piVCCU ist auch was anderes als VCCU!)

Insgesamt bin ich aber auch kein Freund von HM-IP und würde eher zu ZWave raten. Kommt aber darauf an, was du schon hast und ob es Geräte gibt, die den angedachten Zweck auch erfüllen (Alternativen für FB-Heizung war schwierig).

@TE:
Überhaupt: Nimm dir den Zoo vor, den du bereits hast und schau bei jedem Gerät (insbesondere den Schnittstellen wie z.B. HUE-Bridge), ob das nicht direkt unterstützt wird. Dürfte einfacher sein, als jedes Mal das Rad neu zu erfinden...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wetterhexe

#6
FHEM und CCU auf einem raspi parallel würde ich nicht betreiben, schon allein wg. performance.

Zitat
Die HomeMatic Komponenten (OHNE IP) könntest du auch direkt an fhem anbinden...
...aber ich würde da nicht mischen: also HMohneIP an fhem und HMmitIP dann an CCU und per HMCCU in fhem...
...sondern gleich alles an die CCU und dann per HMCCU-Modul in fhem.
Mischbetrieb läuft seit einigen Wochen bei mir im Echtbetrieb ohne Probleme. Ok ich war zu faul >80 devices ab- und wieder anzulernen, und Dutzende notify's zu ändern ;)

Zitat
Soweit mir bekannt läuft HomeMatic IP mit CCU auch lokal ohne Internet und Cloud...
...aber da vielleicht noch mal im Internet recherieren (habe kein HomeMatic IP).
ja das geht, nur das anlernen von neuen Komponenten ist mühsam (benötigt KEY und SGTIN, wird beides mitgeliefert). Mit Internet ist es ein Tastendruck. Cloud brauchts dafür keine

Zitat
Ich lese grad (noch mal): du hast ja schon eine HMIP-Zentrale!? CCU2/CCU3? Die dann "einfach" per HMCCU-Modul in fhem einbinden...
der HmIP Hub geht nicht mit FHEM, er braucht eine CCU

Ich habe lange überlegt ob ich HmIP einsetze oder doch lieber zwave. HmIP hat aber mittlerweile Komponenten die ich schon länger haben wollte, (zB. BSL oder SPDR), die gibts bei keinem anderen System

Beta-User

Zitat von: Wetterhexe am 04 Dezember 2018, 11:42:38
FHEM und CCU auf einem raspi parallel würde ich nicht betreiben, schon allein wg. performance.
Es scheint einige zu geben, die das so nutzen, kommt wohl auf den Anwendungsfall an. Würde eh' grundsätzlich überlegen, ob es wirklich ein Pi sein soll (ein OCCU-Container sollte auch auf einer x86-Hardware laufen und man ist alle Performance-Themen und die SD-Karte tendenziell los, muß das PCB dann halt an einen USB-Seriell-Wandler ranbasteln).

Wenn man aber einsteigt und bisher keine CUL_HM-Devices hat, würde ich eher vom Mischbetrieb abraten (bin wie gesagt aber gar kein CCU-Freund! HM_CUL ist super, wenn man nur BidCoS einsetzt...).

Irgendwo gab es auch ein script, um den HmIP-Hub einzubinden, ist aber eine Variante, die vermutlich nicht den Aufwand lohnt (cloud-Abhängigkeit und dann ein wenig genutzes script...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wetterhexe

Zitat von: Beta-User am 04 Dezember 2018, 12:02:48
Würde eh' grundsätzlich überlegen, ob es wirklich ein Pi sein soll (ein OCCU-Container sollte auch auf einer x86-Hardware laufen und man ist alle Performance-Themen und die SD-Karte tendenziell los, muß das PCB dann halt an einen USB-Seriell-Wandler ranbasteln).
also ich mag Pi's, aber FHEM würde ich auch nicht drauf laufen lassen (hab ich auf x86). Spätestens mit Grafana/mysql ist ein Pi sowieso überfordert.

Pi und SD-Karte ist nicht die große Liebe, da hab ich im Lauf der Jahre auch einiges verschlissen. Deswegen unbedingt mit einem vollautomatischen (und überwachten!) backup und getestetem(!) restore.
Vor zwei Wochen hats eine SD-Karte gegrillt, nach 1 Std. war alles wieder up.

MadMax-FHEM

@Beta-User:

jaja hast schon recht es geht das "alte" Modul auch für eine CCU dann aber eher CCU2, oder!?

Mit dem neuen ist es ja dann quasi Charly also CCU3...

Bin aber bzgl. HomeMatic nicht so tief drin, wenn es drum geht: CCU und HMCCU...
...ich habe alle HomeMatic die ich habe direkt per HM-CFG-USB / HM-PCB an meinen Systemen...

@Wetterhexe & Beta-User:

Ich habe auch schon oft gelesen, dass beides auf einem PI wohl gut läuft.
Habe allerdings keine Ahnung wie groß die Installationen jeweils sind/waren.

Ich selbst würde auch nicht zu viel auf eine HW packen...
...noch dazu wenn (evtl.) ein "spezielles" (angepasstes) Linux drunter läuft/laufen muss...

Zu viele evtl./mögliche Probleme mit Abhängigkeiten...

Und wenn mal eines der beiden Systeme die Grätsche macht (z.B. weil ein Update etc. "Müll" ist) muss man (meist) gleich alles neu aufsetzen...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Keine Ahnung was CCU2/CCU3 angeht. So wie ich das verstanden habe, ist eine CCU3 halt eigentlich ein Pi3 (bisher: irgendwas lahmes anderes) - damit soll (?) der Kritik begegnet werden, die CCU2 wäre lahm...
Spielt alles m.E. keine Rolle, wenn man eine potente Plattform drunter legt :) . Ob das Funkmodul groß anders ist?

Was das Einrichten usw. angeht: Man erkauft sich halt immer beide Seiten der Medaille: Entweder nur ein Gerät (ohne z.B. zu große Abhängigkeit vom LAN/Router, dafür aber komplexer) oder eben zwei zu wartende Geräte.

Aber wie man das am besten aufzieht: k.A., OCCU gibt's z.B. als Docker (?).
Meine persönliche Device: Hände weg von eQ-3 und ganz speziell von HM-IP (ich sag' nur: Kondensatoren, und für tolle firmware sind die auch nicht berühmt...). Deswegen für Anfänger eher was, was "direkt" geht => ZWave, z.B.....

Just my2ct ;)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

FHEM_ASB

So, wollte mich mal melden und Feedback geben. Habe nun als Hardware einen Rasperry B+ mit RPI-RF-MOD am laufen. Als Software laufen piVCCU3 und FHEM. Läuft bislang bestens, ist aber natürlich nicht ansatzweise ausgelastet. Habe testweise einige HM sowie HMIP Geräte bei Qivicon abgemeldet und an der piVCCU angemeldet. Bin zuerst erstaunt über die Optionsvielfalt der Geräte.

Nächster Schritt, FHEM soll genutzt werden, Ziel sind Technoline Sensoren, Schaltsteckdosen sowie die Schellenberg Rollladensteuerung. Allerdings scheint es dafür kein Steuerungsmodul zu geben. Werde erstmal einen Cul bestellen und weitersehen. Vielen Dank an euch :-)

Prof. Dr. Peter Henning

Zum Thema Hue: Ich rate auf jeden Fall zu Dresden Elektronik, weil die wohl als Einzige im Stande sind, Änderungen des Status ohne Polling abzufangen und an FHEM weiterzuleiten. Das RPI-RF-MOD blockiert natürlich die Steckleiste => Entweder statt des ZigBee einen ConBee, oder einfach einen billigen zweiten Raspberry Pi. Empfielt sich übrigens auch für RPI-RF-MOD und piVCCU3 (als dritten Raspberry dann).

LG

pah


gloob

Zitat von: Prof. Dr. Peter Henning am 03 Januar 2019, 07:55:11
Zum Thema Hue: Ich rate auf jeden Fall zu Dresden Elektronik, weil die wohl als Einzige im Stande sind, Änderungen des Status ohne Polling abzufangen und an FHEM weiterzuleiten. Das RPI-RF-MOD blockiert natürlich die Steckleiste => Entweder statt des ZigBee einen ConBee, oder einfach einen billigen zweiten Raspberry Pi. Empfielt sich übrigens auch für RPI-RF-MOD und piVCCU3 (als dritten Raspberry dann).

LG

pah

Für den Raspbee von Dresden Elektronik kann man auch wunderbar einen Raspberry Pi Zero nehmen. Schön klein und das Modul steckt einfach oben drauf.
Raspberry Pi 3 | miniCUL 433MHz | nanoCUL 868 MHz | nanoCUL 433 MHz | MySensors WLAN Gateway | LaCrosse WLAN Gateway | SignalESP 433 MHz | SignalESP 868 MHz | HM-MOD-UART WLAN Gateway | IR - 360 Grad WLAN Gateway

Beta-User

Zitat von: gloob am 03 Januar 2019, 08:15:43
Für den Raspbee von Dresden Elektronik kann man auch wunderbar einen Raspberry Pi Zero nehmen. Schön klein und das Modul steckt einfach oben drauf.
Zitat von: Prof. Dr. Peter Henning am 03 Januar 2019, 07:55:11
Zum Thema Hue: Ich rate auf jeden Fall zu Dresden Elektronik, weil die wohl als Einzige im Stande sind, Änderungen des Status ohne Polling abzufangen und an FHEM weiterzuleiten. Das RPI-RF-MOD blockiert natürlich die Steckleiste => Entweder statt des ZigBee einen ConBee, oder einfach einen billigen zweiten Raspberry Pi. Empfielt sich übrigens auch für RPI-RF-MOD und piVCCU3 (als dritten Raspberry dann).
...und dabei immer dran denken, dass man jeweils die gesamte Software (insbesondere das OS) stets aktuell hält :) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files