FHEM Hosting / FHEM in der Cloud

Begonnen von FHEMAN, 19 Juli 2020, 12:46:45

Vorheriges Thema - Nächstes Thema

FHEMAN

Hallo zusammen,

für ein paar Nachbarn will ich eine Bewässerungssteuerung auf FHEM Basis (idealerweise) realisieren. Die Kommunikation erfolgt via MQTT (Tasmota).
Ich möchte aber keinen Raspi oder VM bei mir hosten.

Da ich tatsächlich nichts sinnvolles hierzu über die Suche gefunden habe, möchte ich die Frage mal in die Runde werfen:

Kann ich FHEM einfach und kostengünstig hosten?

Oder gibt es für meinen Anwendungsfall bessere, evtl. weniger komplexe Lösungen?

Danke für ein paar Gedankenanstöße!
Ronny
NUC7i5 | PROXMOX | FHEM 6.2 | 1 HMLAND | 2 UART | HM | LMS | HIFIBERRY | DOORBIRD | BLINK | BUDERUS | HUE | ALEXA | MILIGHT | LUFTDATENINFO | MQTT| ZIGBEE2MQTT | INDEGO | ROBOROCK | SMA | APC | OPENWB

MarkusN

#1
Sofern notwendiges Wissen bei dir vorhanden ist (Linux im generellen, Firewall & DynDNS, ggf VPN) ist das absolut machbar. Für Kosten ab etwa 3€/Monat bekommst du bereits VMs (z.B. bei Hetzner) welche selbst mehrere FHEM Instanzen locker stemmen sollten.

Das A und O ist dabei Sicherheit. Mindestens solltest du sicherstellen dass MQTT und FHEM Webif/Telnet Traffic nur von den Anschlüssen deiner Nachbarn möglich ist, zum Beispiel mit Firewallregeln und DynDNS Adressen, sofern die Anschlüsse keine feste IP haben. Wenn möglich würde ich sogar auf VPN zurückgreifen.

edit:

Bedenke das Risiko bei getrennter Verbindung zwischen FHEM und den MQTT devices. Je nachdem wie stabil die Verbindung ist (durch ISP, oder unsaubere Implementierung auf deiner Seite) könnte das duchaus problematisch sein. Gerade bei Bewässerung sollte das schon sehr robust sein. MQTT bietet hier aber gewisserweise einen doppelten Boden durch retained messages.

FHEMAN

Das heißt, ich benötige einen Root Server. Dann fallen die einfachen  Hosting Angebote mit eingeschränktem Zugang schon mal weg.

Oder könnte ich das umgehen mit einem separaten MQTT Broker?

Wenn die MQTT Devices von außen erreichbar sein müssen und deswegen DynDNS, Portforwarding etc. eingerichtet werden muss, sind mir Aufwand (Installation, Wartung) und Fehleranfälligkeit zu hoch.
NUC7i5 | PROXMOX | FHEM 6.2 | 1 HMLAND | 2 UART | HM | LMS | HIFIBERRY | DOORBIRD | BLINK | BUDERUS | HUE | ALEXA | MILIGHT | LUFTDATENINFO | MQTT| ZIGBEE2MQTT | INDEGO | ROBOROCK | SMA | APC | OPENWB

kjmEjfu

Zitat von: FHEMAN am 19 Juli 2020, 12:46:45
Oder gibt es für meinen Anwendungsfall bessere, evtl. weniger komplexe Lösungen?

Die Frage ist eher, was überhaupt der genaue Anwendungsfall ist.
Geht es darum ein paar Ventile anzusteuern, eventuell unter Einbindung von Regensensoren? Dann könntest du auch einfach Bewässerungscomputer von Gardena oder RainBird nehmen.
Bissel mehr Flexibilität bietet z.B. https://opensprinkler.com/ ist auch günstiger ;-)

Welche zusätzlichen Funktionen brauchst du (von FHEM) denn noch?
Migriere derzeit zu Home Assistant

FHEMAN

Es geht um die Programmlogik für Aktoren und Sensoren, viell. noch Wetterdienst. Gardena und Co. sind mir da zu unflexibel.
Ich habe gestern zum ersten Mal Berührung mit MQTT (ESP geflasht mit Sensoren und 4ch Relais). Kostenpunkt sowie die einfache Einbindung in FHEM und das standardisierte Protokoll und Möglichkeiten über LAN/WAN ließen in mir die Idee aufkommen.
NUC7i5 | PROXMOX | FHEM 6.2 | 1 HMLAND | 2 UART | HM | LMS | HIFIBERRY | DOORBIRD | BLINK | BUDERUS | HUE | ALEXA | MILIGHT | LUFTDATENINFO | MQTT| ZIGBEE2MQTT | INDEGO | ROBOROCK | SMA | APC | OPENWB

MarkusN

Zitat von: FHEMAN am 19 Juli 2020, 13:41:09
Das heißt, ich benötige einen Root Server. Dann fallen die einfachen  Hosting Angebote mit eingeschränktem Zugang schon mal weg.

Oder könnte ich das umgehen mit einem separaten MQTT Broker?

Wenn die MQTT Devices von außen erreichbar sein müssen und deswegen DynDNS, Portforwarding etc. eingerichtet werden muss, sind mir Aufwand (Installation, Wartung) und Fehleranfälligkeit zu hoch.

Ja, es würde sich dabei um einen (virtuellen) root Server handeln. Es wäre durchaus auch möglich dort nur den MQTT Broker zu hosten, und FHEM bei dir zuhause.
Die MQTT Geräte müssen nicht von außen erreichbar sein. DynDNS und Firewall habe ich auf die ausgehende Verbindung der MQTT Geräte zum Broker/FHEM bezogen.

FHEMAN

Zitat von: MarkusN am 19 Juli 2020, 14:56:50
Es wäre durchaus auch möglich dort nur den MQTT Broker zu hosten, und FHEM bei dir zuhause.
Die MQTT Geräte müssen nicht von außen erreichbar sein.

Heißt das, alleine mit dem MQTT Broker in der Cloud (feste IP), benötige ich auf Geräteseite und auf FHEM Seite keine Öffnung irgendwelcher Ports etc. nach innen. Da beide Seiten ihre Verbindung nach außen zum Broker aufbauen und halten?
Dann hätte ich nur das Risiko der Erreichbarkeit meiner FHEM Instanz.

Opensprinkler klingt auch ziemlich gut, lässt sich aber leider nicht selbst programmieren.
Ich habe zum Beispiel zeitweise mehr Wasserdurchfluss, da akiltiviere ich temporär einen weiteren Kreis. Oder merke mir die Zeiten und überspringe ggf. Kreise.
NUC7i5 | PROXMOX | FHEM 6.2 | 1 HMLAND | 2 UART | HM | LMS | HIFIBERRY | DOORBIRD | BLINK | BUDERUS | HUE | ALEXA | MILIGHT | LUFTDATENINFO | MQTT| ZIGBEE2MQTT | INDEGO | ROBOROCK | SMA | APC | OPENWB

FHEM-User22

Hallo,
Zitat von: FHEMAN am 19 Juli 2020, 15:20:26
Heißt das, alleine mit dem MQTT Broker in der Cloud (feste IP), benötige ich auf Geräteseite und auf FHEM Seite keine Öffnung irgendwelcher Ports etc. nach innen. Da beide Seiten ihre Verbindung nach außen zum Broker aufbauen und halten?
Dann hätte ich nur das Risiko der Erreichbarkeit meiner FHEM Instanz.

ja, mache ich auch so. Ich habe einige MQTT-Geräte (Gosund) an verschiedenen Orten/Städten und verwende sie in FHEM, als wären sie im Haus. Alles ohne Portfreigabe oder DynDNS.

Grüße
FHEM auf Raspberry Pi und Proxmox und... und.... und....