Monatsrückblick Januar/Februar 2026 ist online!

[Schuko80]

Hallo Zusammen,

ich verzweifel gerade an den Möglichkeiten und bräuchte mal eure Meinung, gerne mit Begründung warum:

Grundlegend:

Das ganze System soll später neben der eigentlichen Haussteuerung auch als Alarmanlage funktionieren,

Ziel ist es also dem Raspberry eine Backuplösung per AKKU und UTMS Stick zu schaffen.

Aktuelles System:

Raspberry 3 mit Z-Wave und Deconz (Zigbee) Aufsteckmodul

Da ich an den Fenstern Reed-Kontakte habe und die Z-Wave Universalplatine nicht mit Batteriebetrieb klar kommt,

war der Gedanke, Homematic mit ins System aufzunehmen. Da es den original USB Stick nicht mehr gibt,

habe ich jetzt diverse Lösungen.

1. Homematic LAN Gateway - CCU2 als Softwarelösung auf Raspberry neben IO Broker:

Nachteil: Wird der Strom abgestellt, ist auch das Netzwerk bzw. das Gateway tot,

dementsprechend keine Kommunikation zwischen LAN Gateway und Raspberry

Vorteil: Original Funkmodul

2. CUL Stick - mit CCU2 als Softwarelösung auf Raspberry neben IO Broker:

Läßt sich der Stick unter IOBroker bzw. CCU2 Software einrichten oder muß ich dann auch noch auf FHEM zugreifen?

Nachteil: Macht auf mich irgendwie den Eindruck einer Bastellösung, bei der man nie genau weiß, ob es läuft

Vorteil: Funksteckdosen auf 433 MHz wären schaltbar (richtig?)

****3. Deconz Modul gegen ConBee (USB Stick) tauschen und Homematic Aufsteckmodul für Raspberry einsetzen -

CCU2 als Softwarelösung auf Raspberry neben IO Broker:****

Nachteil: Funkreichweite?

Vorteil: ?

4. Zweiten Raspberry betreiben mit Homematic Aufsteckmodul und CCU2 als Softwarelösung

Nachteil: Bei Stromausfall keine Kommunikation mehr zwischen den Raspberry's wegen dem toten

Netzwerk / Erhöhter Stromverbrauch durch zwei Rechner

Vorteil: IOBroker könnte als Multihost laufen, wenn es zu groß wird und die Last somit verteilen

Was passiert, wenn der erste Host nicht mehr mit dem zweiten sprechen kann?

So, nun seit ihr an der Reihe, vielleicht habe ich ja was wichtiges übersehen!

[Dutchman]

Ich würde für Option 4 tendieren und dazu einen ups und mit der Spannung davon auch die Netzwerkkomponenten betreiben so hab ich es auch

• esxi Host

• verschiedene Raspberry

• ip cams

• alles obek genannte per UPS für Stromausfall gesichert

–-----------------------

Send from mobile device

[paul53]

Zu 2. Das geht mit https://doc.homegear.eu/data/homegear-homematicbidcos/configuration.html#communication-modules als Interface zwischen BidCos-RF und hm-rpc. Nachteil: Kein HmIP.

BidCos-RF und 433 MHz lassen sich nicht parallel mit dem gleichen CUL betreiben.

Zu 3. Vorteil: BidCos-RF <u>und</u> HmIP (piVCCU)

Zu 4. Multihost ist evtl. erforderlich bei vielen Adaptern (VIS, Wetter, …). Wenn der Slave nur Dinge ausführt, die bei Netzspannungsausfall nicht unbedingt funktionieren müssen (Multimedia, Licht, ...), ist die USV nur für den Master erforderlich.

[Schuko80]

Eine USV würde ich mir eigentlich ungerne anschaffen - Platz, Kosten und Nutzwert

Hatte für den Raspberry mehr an eine Power Bank oder so gedacht, um eine gewisse Zeit zu überbrücken.

Im 4. Fall würde die Lösung bedeuten, das ich lediglich eine Meldung verschicke, das die Stromversorgung unterbrochen und damit auch das Alarmsystem ausgefallen ist. Schön ist das natürlich nicht…

[paul53]

@Schuko80:

Eine USV würde ich mir eigentlich ungerne anschaffen - Platz, Kosten und Nutzwert

Hatte für den Raspberry mehr an eine Power Bank oder so gedacht, um eine gewisse Zeit zu überbrücken. `
Power Banks sind dafür nicht ausgelegt. Eine https://www.rasppishop.de/SUSV-pi-basic-USV-fuer-den-Raspberry-Pi ist auch nicht viel teurer und liefert noch eine RTC und die Informationen über Netzspannungsausfall und -wiederkehr. So kann man bei Netzspannungswiederkehr alle netzbetriebenen Aktoren wieder in den Sollzustand versetzen.
@Schuko80:

das ich lediglich eine Meldung verschicke, das die Stromversorgung unterbrochen und damit auch das Alarmsystem ausgefallen ist. `
Das Alarmsystem muss natürlich vollständig auf dem Master mit der USV realisiert werden, es sei denn es enthält netzabhängige Komponenten - dann ist bei Netzausfall ohnehin alles zu spät.

[paul53]

@Schuko80:

Aktuelles System:

Raspberry 3 mit Z-Wave und Deconz (Zigbee) Aufsteckmodul `
Dient Zigbee noch für andere Sachen als für Lichtsteuerung ?

Da Licht ohnehin netzabhängig ist, könnte das Zigbee-Modul auf dem RPi 3 als Slave verbleiben und für den Master würde ich einen RPi 2 (etwas geringere Stromaufnahme als RPi 3) mit dem HM-Funkmodul und dem Z-Wave-Stick verwenden.

[Schuko80]

@paul53:

@Schuko80:

Eine USV würde ich mir eigentlich ungerne anschaffen - Platz, Kosten und Nutzwert

Hatte für den Raspberry mehr an eine Power Bank oder so gedacht, um eine gewisse Zeit zu überbrücken. Power Banks sind dafür nicht ausgelegt. Eine [https://www.rasppishop.de/SUSV-pi-basic-USV-fuer-den-Raspberry-Pi](https://www.rasppishop.de/SUSV-pi-basic-USV-fuer-den-Raspberry-Pi) ist auch nicht viel teurer und liefert noch eine RTC und die Informationen über Netzspannungsausfall und -wiederkehr. So kann man bei Netzspannungswiederkehr alle netzbetriebenen Aktoren wieder in den Sollzustand versetzen.

Evtl. habe ich mich falsch ausgedrückt, gedacht hatte ich da z.B. an PiUSV+ mit einer Powerbank, einfach unter dem Hintergrund (unwahrscheinlich. aber möglich) Einbrecher dreht im Keller (Mehrfamilienhaus) den Saft ab und steigt ein, der Pi sollte also sag ich mal eine gute Stunde weiterlaufen können. Soweit ich gelesen habe, ist das wohl möglich damit.@paul53:

@Schuko80:

Aktuelles System:

Raspberry 3 mit Z-Wave und Deconz (Zigbee) Aufsteckmodul `
Dient Zigbee noch für andere Sachen als für Lichtsteuerung ?

Da Licht ohnehin netzabhängig ist, könnte das Zigbee-Modul auf dem RPi 3 als Slave verbleiben und für den Master würde ich einen RPi 2 (etwas geringere Stromaufnahme als RPi 3) mit dem HM-Funkmodul und dem Z-Wave-Stick verwenden. `

Aktuell dient Zigbee nur der Lampensteuerung, mich hat bisher halt gestört, dann zwei Systeme laufen zu haben. RPI2 würde ich aber nicht nehmen, wenn dann den 3er, auf die 2,- Euro Strom kommt es dann auch nicht an.

Macht es ansonsten evtl. auch Sinn auf ein Tinkerboard oder Rock64 als Master zurück zu greifen?

Wie stellen sich zwei ordentlich aufgestellte RPI3 im Host gegenüber einem einzelnen Tinkerboard in der Perfomance an?

Bzw. angenommen ich nehme einen zweiten RPI3, wäre dieser zur VIS Darstellung besser als ein Tablet, dann könnte man zwei Fliegen mit einer Klappe schlagen:

Master + Slave mit Zigbee und VIS

[Dutchman]

Kurz ne andere Frage noch

Du sagst in deinen scenario er dreht den Saft ab und der pi soll laufen bleiben als Alarm Anlage?

Wie löst er Alarm aus/schikt das Signal wenn kein Saft da ist pushover usw kannst du ja vergessen ohne Internet.

Alarm oder ähnlich auch auf Batterie?

–-----------------------

Send from mobile device

[paul53]

@Schuko80:

auf die 2,- Euro Strom kommt es dann auch nicht an. `
Natürlich nicht. Geringere Stromaufnahme verlängert die Stützzeit des Akkus.
@Schuko80:

Macht es ansonsten evtl. auch Sinn auf ein Tinkerboard oder Rock64 als Master zurück zu greifen? `
Mit dem Tinkerboard wird kein Multhost-System erforderlich sein, denn es hat ausreichend RAM (2 GB) und ist sehr performant. Damit bietet sich Variante 3 an.

Auf dem Rock64 kann man (zur Zeit) kein HM-Funkmodul (und wahrscheinlich auch kein anderes GPIO-Modul) betreiben, denn irgendwo ist die Baudrate der UART des Rock64 auf 1,5 MBit/s festgelegt. Somit funktionieren nur USB-Modems.

[Schuko80]

@Dutchman:

Wie löst er Alarm aus/schikt das Signal wenn kein Saft da ist pushover usw kannst du ja vergessen ohne Internet.

Alarm oder ähnlich auch auf Batterie? `

Angedacht war es, auf Dauer einen UTMS Stick zu nehmen - hiermit würde sich eine Alarmmeldung wie auch eine Meldung, wenn der Akku fast leer ist, verschicken.

Dann wäre ich also bei Lösung 3, erst mal mit Pi, solange der reicht und dann Wechsel auf Tinkerboard oder Lösung 4 - stellt sich jetzt die Frage, was ist besser, ein Tinkerboard oder zwei Rpi3. Fragt sich auch, ob fürs VIS Android mit Tablet oder RPI mit Linux besser wäre