FHEM nur mit kompatiblen WLAN Geräten betreiben

Begonnen von stewen, 22 Oktober 2021, 13:00:38

Vorheriges Thema - Nächstes Thema

stewen

Hallo,

ich betreibe seit über 10 Jahren FHEM, und mein Aufbau entspricht wohl der klassischen "über die Jahre angewachsen"-Struktur. So habe ich FS20 über CUL, Homematic, HUE, Osram, EnOcean, Zigbee, JeeLink und und und in meinem System. Vor etwa vier Jahren habe ich meine FHEM Hauptinstanz virtualisiert (mittlerweile auf einem Proxmox Cluster) und habe daher die ganzen Sender/Antennen/Bridges an einen RaspberryPi ins LAN gehängt. Das hat seither wirklich gut funktioniert.

Trotzdem würde ich nun gerne diesen "Single Point of Failure" aus meinem System bekommen und frage mich, ob es für die üblichen Sensoren/Aktoren mittlerweile Alternativen ohne eigenes Protokoll gibt. Ich betreibe seit etwa einem Jahr ein paar Shelly Steckdosen mit Leistungsmessung, die einfach über WLAN eingebunden und in FHEM angesprochen werden. Ähnliches würde ich mir wünschen für H/T-Sensoren, Bewegungsmelder, Wandtaster, ...
Wie sieht es aus? Hat hier jemand bereits den Schritt gewagt und die ganzen Bridges und Antennen über Bord geworfen?

Danke und schönes WE!
Stephan
FHEM auf Proxmox Cluster - viele Sender/Adapter an Raspberry Pi 3 mit LAN angebunden (ser2net) - schon ewig dabei.

rudolfkoenig

Achtung: Heim-WLAN Router sind nicht in der Lage, eine grosse Menge an Clients gleichzeitig zu bedienen, uebliche Grenzen liegen zwischen 15 und 30 Geraeten.

Papa Romeo

#2
Zitat von: stewen am 22 Oktober 2021, 13:00:38
... die einfach über WLAN eingebunden und in FHEM angesprochen werden... 

...hab noch nie was anderes gemacht. Bei mir ging, bzw. geht der verbliebene Rest ausschließlich über MQTT

LG
Papa Romeo

EDIT: ... hab ich vergessen. Meine MAX-Thermostate laufen über den MAX-Cube und sind über diesen in Fhem eingebunden.
...die richtige Lötspitzentemperatur prüft man zwischen Daumen und Zeigefinger.
...überlasse niemals etwas einer Software, das du hardwaremässig erreichen kannst.
...unvorsichtige Elektriker werden schnell zu leitenden Angestellten.
und...never change a running System...no Updates if not necessary

MadMax-FHEM

Zitat
Trotzdem würde ich nun gerne diesen "Single Point of Failure" aus meinem System bekommen...

Und wie ist/soll damit der single point of failure weg sein?
Damit hast du doch nur einen anderen?

Und wenn nun alle Sensoren/Aktoren nur noch über WLAN laufen, dann hast du doch danach EINEN single point of failure für ALLE Geräte.

Zuvor ja nur "partiell", also:

Zigbee fällt aus -> Zigbee Geräte "weg"
ZWave fällt aus -> ZWave Geräte "weg"
usw.

Zitat
... frage mich, ob es für die üblichen Sensoren/Aktoren mittlerweile Alternativen ohne eigenes Protokoll gibt.

Alle haben ein Protokoll!
WLAN ist ja nur der Übertragungsweg!

Irrglaube: wenn ein Gerät per WLAN angebunden ist, dann kann es automatisch integriert werden. Falsch, weil es ja nicht heißt, dass die empfangenen (über den Übertragungsweg WLAN) Daten auch "verstanden" werden (Protokoll)...

Und es gibt ja von Shelly: H/T, BWM, mittels uni -> alles mögliche usw.

Aber da wäre ich auch vorsichtig, weil zu viele WLAN-Geräte ja auch irgendwann problematisch werden können...

Und wie (eingangs geschrieben) wenn WLAN "ausfällt", dann ist ja gleich "alles weg"...

Viel Erfolg, 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)

frank

ZitatIrrglaube: wenn ein Gerät per WLAN angebunden ist, dann kann es automatisch integriert werden. Falsch, weil es ja nicht heißt, dass die empfangenen (über den Übertragungsweg WLAN) Daten auch "verstanden" werden (Protokoll)...
das wär ja die absolute katastrophe, wenn jedes wlan gerät, dass bei mir vorbei geht oder fährt, automatisch ein device erzeugen würde.
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

stewen

Hallo, danke schonmal für die Antworten. Ich habe mein WLAN bereits vor einiger Zeit so ausgelegt, dass ich mehrere Sender habe, die vom Signal her sehr großzügig über das gesamte Haus überlappen. Zudem habe ich ein Technik-WLAN, das zwecks Adressierung über ein separates VLAN läuft. Konkret habe ich derzeit sechs Unifi Access Points der Pro Serie (alle direkt verkabelt) laufen, das sollte also schon passen. Sollte das WLAN doch mal ausfallen, wäre sowieso der Teufel los (Frau und Kinder :P).

Welche Geräte haben die, die bereits WLAN als Übertragungsweg nutzen, konkret im Einsatz (kompatibel mit FHEM)? Hier würden mich vor allem - wie bereits erwähnt - Sensoren für Temp/Feuchte und Bewegungsmelder interessieren. Zudem bin ich eigentlich seit Jahren auf der Suche nach dem "idealen" Wandtaster, habe hier Homematic, EnOcean und HUE am Start, die stellen mich alle nicht sonderlich zufrieden (teils optisch, teils haptisch). Je weniger Sender ich umständlich in meine VM bringen muss desto glücklicher wäre ich ...

MQTT hab ich zwar seit Jahren verfolgt (seit ich mit ein paar MySensors gespielt habe), aber nie ins Stammsystem übernommen. Das würde zusätzlich ebenfalls in Frage kommen.
Ich spiele auch immer wieder mal mit dem Gedanken, ioBroker zu integrieren, aber was soll ich sagen ... ich stehe einfach auf FHEM  :-*
FHEM auf Proxmox Cluster - viele Sender/Adapter an Raspberry Pi 3 mit LAN angebunden (ser2net) - schon ewig dabei.

MadMax-FHEM

#6
Überlappend mit gutem Kanalplan, nicht dass du dir selbst die "Luft" "kaputt" machst... ;)

Inkl. Nachbarschaft... ;)
(sofern vorhanden)

Dann noch mal mit Links ;)  :

https://shelly.cloud/products/shelly-humidity-temperature-smart-home-automation-sensor/

https://shelly.cloud/knowledge-base/devices/shelly-motion/

Der Motionsensor soll ja ganz gut sein...
...bis auf die Optik war ich allerdings mit dem H/T nur bedingt zufrieden...
EDIT: ich war allerdings auch "early adaptor"... Evtl. sind die neueren Varianten ja besser...

Bzgl. Haptik/Optik: ich schaue halt, dass ich Unterputzmodule bekomme, dann kommt "oben drauf" der "normale" Schalter/Taster...
Oder es halt was gibt, was zu meiner Schalterserie passt...

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)

stewen

FHEM auf Proxmox Cluster - viele Sender/Adapter an Raspberry Pi 3 mit LAN angebunden (ser2net) - schon ewig dabei.

Beta-User

Zitat von: stewen am 22 Oktober 2021, 15:09:39
MQTT hab ich zwar seit Jahren verfolgt (seit ich mit ein paar MySensors gespielt habe), aber nie ins Stammsystem übernommen. Das würde zusätzlich ebenfalls in Frage kommen.
Falls du einen Anlauf mit MQTT machen willst, wäre allerdings zu empfehlen, statt der MQTT_.*-Modulfamilie dann auf MQTT2_.* zu setzen. Das "kann" deutlich besser mit JSON-Strukturen umgehen, und es gibt praktisch zu jeder Implementierung der "großen" Systeme (insbes. zu ZigBee) eine "-2MQTT"-Variante (die dann typischerweise JSON verwendet...).

Eventueller Einstiegspunkt: https://wiki.fhem.de/wiki/MQTT#Schnellstart_f.C3.BCr_Ungeduldige

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

stewen

Danke für den Link, Beta-User, werd ich mir auf jeden Fall mal anschauen. Ich finde das schon interessant, aber momentan kann ich mangels Zeit noch nicht einsteigen ...
FHEM auf Proxmox Cluster - viele Sender/Adapter an Raspberry Pi 3 mit LAN angebunden (ser2net) - schon ewig dabei.

Apollon

#10
Hallo,
ich gebe noch zu bedenken, dass 434 und 868 Mhz besser Hindernisse durchdringen. Beim WLan kommt es schon mal vor, dass es an einigen Stellen nicht verfügbar ist.

Ich hatte in einer Betongrotte, die nur ca. 8 m vom Router entfernt ist, kein WLan mehr. Mit einem 868 Mhz-Aktor habe ich an dieser Stelle keinerlei Probleme.

Gruß
Apollon

Wernieman

Und WLAN braucht mehr Strom als z.B:  434/868 MHz Geräte. Echter langer Batteriebetrieb ist mit WLAN schwierig. Liebe zar mittlerweile auch meine Tasmota Dosen und wo die Stecken, gibt es auch Strom. trotzdem gibt es immer Stellen, wo ein Batteriebetrieb sinnvoll ist.

Prinzipiell wirst Du um verschiedene Gateways nicht "rumkommen", schon um die diversen Protokolle zu unterstützen.
Hinweis: Gateway kann auch rein Softwaretechnisch sein.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html