FHEM Neuaufbau: Welche Basis

Begonnen von bolzomane, 13 Mai 2016, 09:51:07

Vorheriges Thema - Nächstes Thema

bolzomane

Hallo,

ich betreibe aktuell FHEM rudimentär auf einer Fritzbox um eine AVM DECT Dose und eine AV Receiver zu schalten.
Zukünftig möchte ich jedoch ein bisschen mehr machen, als nächsten Schritt möchte ich eine Wetterstation anschaffen und integrieren.
Dannach sollen Rolladensteuerung, Heizung, Rauchmelder folgen.

Da ich bei null anfange möchte ich versuchen jetzt schon auf einen (funk) Standard zu gehen mit dem ich all diese Geräte ansteuern kann. Vorhanden sind 2 weitere Fritzboxen (auf jeder Etage eine) und CAT Verkabelung in jedem Raum. Ich habe schon ein wenig quergelesen und stelle mit vor auf Homematic zu setzen, ein USB Stick an jede FB, und mittels FHEM2FHEM diese miteinander kommunizieren zu lassen wobei einer dann als Master fungieren soll.

Klingt das nach einem machbaren und sinnvollem plan oder liege ich da völlig falsch?

Tedious

Soweit ich weiß (Vorsicht, Halbwissen) können die Clients bei FHEM2FHEM nur Parameter übergeben, nicht selbst auslösen. Sprich, Daten empfangen und an den Master weitergeben ist kein Problem, vom Master einen Befehl empfangen und denn per eigenem CUL senden geht nicht - soweit ich weiß....
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

Wernieman

Also Laut Doku:
http://fhem.de/commandref.html#FHEM2FHEM
ZitatRAW
By using this type the local FHEM will receive raw events from the remote FHEM device devicename, just like if it would be attached to the local FHEM. Drawback: only devices using the Dispatch function (CUL, FHZ, CM11, SISPM, RFXCOM, TCM, TRX, TUL) generate raw messages, and you must create a FHEM2FHEM instance for each remote device.
devicename must exist on the local FHEM server too with the same name and same type as the remote device, but with the device-node "none", so it is only a dummy device. All necessary attributes (e.g. rfmode if the remote CUL is in HomeMatic mode) must also be set for the local device. Do not reuse a real local device, else duplicate filtering (see dupTimeout) won't work correctly.

Aber auch bei mir gilt: Gefährliches Halbwissen.

Würde aber an anderen Stelle einharken:
a)
Dir ist klar, das die FritzBoxen bezüglich FHEM ein Auslaufmodel? Aus diversen (teils verständlichen) Gründen schränkt AVM die Fritzboxen immer mehr ein. Auch gibt es bei diversen Perl Modulen keine für die Box. Deshalb die Frage, ist nicht ein Kleinstrechner (RasPi und co nicht optimaler
b)
FHEM kann seine Stärken gerade in der Interoperabilität von verschiedenen Produkten verschiedener Hersteller ausspielen. Da bisher kein einzelnder Standard (Hersteller) alle Bedürfnisse erfüllt, kommt es zwangsläufig dazu, das mehrere Empfänger/Sender am FHEM angeschlossen werden.
Entsprechend ist folgende Aussage etwas "kritisch" zu hinterfragen
Zitatich versuchen jetzt schon auf einen (funk) Standard zu gehen mit dem ich all diese Geräte ansteuern kann.

Ansonsten .. wurde vieles davon schon hier im Forum diskutiert und die Vor/Nachteile erörtert. Einfach mal nachlesen .....
- 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

fiedel

Meine Empfehlung wäre: FHEM auf üblichem Minirechner (du musst nur 1 System pflegen und bist nicht limitiert wie auf der FB) an dem ein HM- USB- Stick steckt. An die Fritzbox(en) hängst du jeweils HM-LAN- Adapter. Alle HM- Adapter bündelst du dann in FHEM mit der VCCU. Über freie LAN- Kabel oder freie Adern (für 100er LAN werden nur 4 Adern genutzt - es gibt entsprechend LAN-Kabel- Splitter) können dann noch 1-Wire- Komponenten angebunden werden. Dazu dann gleich einen vollwertigen Busmaster einsetzten.

Gruß
Frank
FeatureLevel: 6.1 auf Wyse N03D ; Deb. 11 ; Perl: v5.14.2 ; IO: HM-MOD-RPI-PCB + VCCU|CUL 868 V 1.66|LinkUSBi |TEK603
HM: SEC-SCO|SCI-3-FM|LC-SW4-PCB|ES-PMSW1-PL|RC-4-2|SEN-MDIR-O|SEC-WDS-2
CUL: HMS100TF|FS20 S4A-2 ; OWDevice: DS18S20|DS2401|DS2406|DS2423

Beta-User

Das ist alles ziemlich Geschmackssache und
- dann auch eine Frage des eigenen Wissens/Könnens bzw. Dazulernens (Wenn man mir vor 2,5 Jahren gesagt hätte, was ich heute so alles an Spielereien im Haus verbaut und dabei selbst gemacht habe, hätte ich den Betreffenden laut ausgelacht... ;D).
- der Größe des gewünschten Budgets ;).

Nach meinem persönlichen Geschmack:
- ein Minirechner, wobei ich FHEM-Only auf einem RPI2@raspbian habe; dar ist dann im Havariefall auch schnell mal getauscht, wenn man sonst nicht viel dran rumkonfiguriert (=> keine GPIO-Nutzung, andere Serverdienste usw.; sonst muß man sich über Backups des Gesamtsystems noch mehr den Kopf machen); das setzt aber Linux-Grundkenntnisse voraus (oder den Willen, sich da wenigstens etwas anzueignen)
- HM ist in vielen Fällen sehr solide, bidirektional und in den Kernbereichen stimmt m.E. Preis-/Leistung. Das macht bei mir die "notwendigen" und WAF-wichtigen Dinge und 230V. Für's ganze Haus reicht bei mir aber ein CUL mit der großen Antenne; 2 Stockwerke und Wände sind kein echtes Problem. Sieht evtl. anders aus, wenn mehr Stahl verbaut ist. Heute würde ich vermutlich versuchen, gleich den Eigenbau-CUL aufzubauen.
Über FHEM2FHEM würde ich mir jedenfalls erst dann einen Kopf machen, wenn es funktechnisch wirklich Probleme gäbe. Und dann gab es da noch die HM-Lan-Adapter... Ethernet ist ja vorhanden

- Für die ganze übrige Sensorik nehme ich jetzt praktisch nur noch MySensors. Hat etwas gedauert, bis ich mich da rangetraut habe, ist aber wirklich flexibel, fast peinlich billig und auch zuverlässig.
- Die Anbindung einer Wetterstation (was soll die können? Temp., Luftfeuchte, Luftdruck und -Änderungen kann z.B. auch MySensors direkt; Wind und -Geschwindigkeit habe ich mir für später aufgehoben (solar powered 8))) ist ein spezielles Thema, da gibt es direkte 433MHz-Anbindungen für gängige Sensoren, HM (m.E. zu teuer und teilweise sehr kritisch beurteilt) .............

Ansonsten kann ich dem hier nur zustimmen:
Zitat von: Wernieman am 13 Mai 2016, 10:17:11
FHEM kann seine Stärken gerade in der Interoperabilität von verschiedenen Produkten verschiedener Hersteller ausspielen. Da bisher kein einzelnder Standard (Hersteller) alle Bedürfnisse erfüllt, kommt es zwangsläufig dazu, das mehrere Empfänger/Sender am FHEM angeschlossen werden.
Entsprechend ist folgende Aussage etwas "kritisch" zu hinterfragen
Ansonsten .. wurde vieles davon schon hier im Forum diskutiert und die Vor/Nachteile erörtert. Einfach mal nachlesen .....

Andererseits erscheint es mir weise, die Zahl der eingesetzten Techniken eher gering zu halten und erst dann was neues zu nehmen, wenn man mit dem bereits erkundeten nicht weiterkommen kann oder will. Nach Jahren wieder durchblicken ist auch eine Wissenschaft für sich ::)

Also viel Freude am Erkunden des Reichs der fast unendlichen Möglichkeiten!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors