Einsteigern helfen: YouTube-Tutorial-Reihe für FHEM

Begonnen von haus-automatisierung.com, 16 Mai 2016, 20:07:04

Vorheriges Thema - Nächstes Thema

haus-automatisierung.com

- gelöscht -
Ex-FHEM-Nutzer. Inaktiv.

fiedel

Absolut toll, was du da auf die Beine gestellt hast! Auch die Webseite gefällt mir sehr. Dein Youtube- Channel sollte rot und fett im Forum angepinnt werden. Das ist genau das, was viele Einsteiger brauchen um über die ersten Hürden zu kommen.  Ganz "großes Kino" im wahrsten Sinne des Wortes!  ;)

Meine größten Schwierigkeiten am Anfang waren CUL flashen, den ersten Temperatursensor, Funktaster, Aktor definieren und zum laufen bringen, sowie erste Plots erstellen. Das hätte mit deinen Videos wenige Stunden, statt mehrerer Tage, bzw. Wochen (Plots waren damals noch schwieriger zu erstellen) gedauert.

Heute würde mich (und sicher einige andere) am meisten interessieren, wie man NGINX als Reverseproxy vor FHEM schaltet und so absichert, dass man es guten Gewissens im Router freigeben und jederzeit (per Login) von draussen darauf zugreifen kann.

Viele Grüße und weiter so!
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

KölnSolar

Am Anfang denkt man: Funk soso, ja wenn die Frequenz stimmt(die gibt ja jeder device-Hersteller an), dann werden wohl 2 Geräte gleicher Frequenz kommunizieren können ;D
Als 2. lernt man dann, dass nicht jeder Transceiver/Receiver alle Protokolle, die in fhem integriert sind, empfängt und legt sich weitere Transceiver/Receiver zu, weil die Aktoren/Sensoren hat man natürlich schon vorher gekauft ;D
Und schließlich lernt man den Aufbau von Funkprotokollen, also Kodierung von Highs and Lows, Pulsweiten etc. kennen

und dann hat man verstanden, was da so im Äther passiert (oder manchmal eben auch nicht)

Ist es nicht ein kleines Wunder, dass bei dem ganzen WLAN,Bluetooth, GSM, LTE Funk auch noch smarthome über Funk funktioniert  ;)
Grüße, Markus
Nur löten kann ich immer noch nicht, nur braten  :-[
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

PeMue

Zitat von: KölnSolar am 04 Juni 2016, 10:28:34
Nur löten kann ich immer noch nicht, nur braten  :-[
Nimm einen Dispenser, einen Severin Pizzaofen und eine entsprechende Regelung dann klappt's auch bei Dir  ;D ;D ;D
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

Benni

Zitat von: haus-automatisierung.com am 06 Juni 2016, 09:31:56
Das Thema Reverseproxy klingt interessant!
Passt auch gut zu einem geplanten Video, in welchem ich FHEM von außen zugänglich machen möchte per DynDNS.

Das klingt nicht nur interessant, sondern ist m.E. untrennbar, wenn man FHEM(WEB) von außen zugänglich machen möchte, ebenso wie hier auch SSL dazugehört.

Ich weiß zwar nicht, wie du das DynDNS-Tutorial im Detail geplant hast, aber nur das zugänglich machen per DynDNS (und simplem Port-Forwarding) ist einfach nur fahrlässig!

Anfängern die Angst nehmen ist sehr gut! Aber echte Gefahren zu "überspielen" oder gar zu unterschlagen wäre das Gegenteil.

Der vernünftigste Weg von außen auf FHEM zuzugreifen ist und bleibt aber definitiv der Weg über VPN.
(Wobei auch hierfür natürlich i.d.R. ein DynDNS-Zugang benötigt wird)

Bitte nicht als böse Kritik verstehen, das is nur das was mir Spontan dazu eingefallen ist und was m.E. in einem entsprechenden Tutorial auf jeden Fall Erwähnung finden sollte.

Gruß Benni.

Beta-User

Zitat von: KölnSolar am 04 Juni 2016, 10:28:34
Am Anfang denkt man: Funk soso, ja wenn die Frequenz stimmt(die gibt ja jeder device-Hersteller an), dann werden wohl 2 Geräte gleicher Frequenz kommunizieren können ;D
Als 2. lernt man dann, dass nicht jeder Transceiver/Receiver alle Protokolle, die in fhem integriert sind, empfängt und legt sich weitere Transceiver/Receiver zu, weil die Aktoren/Sensoren hat man natürlich schon vorher gekauft ;D
Und schließlich lernt man den Aufbau von Funkprotokollen, also Kodierung von Highs and Lows, Pulsweiten etc. kennen

und dann hat man verstanden, was da so im Äther passiert (oder manchmal eben auch nicht)

Ist es nicht ein kleines Wunder, dass bei dem ganzen WLAN,Bluetooth, GSM, LTE Funk auch noch smarthome über Funk funktioniert  ;)
Grüße, Markus
Nur löten kann ich immer noch nicht, nur braten  :-[
...ist es wirklich so einfach? Dann sollte es auch kein Problem sein, beliebte Funkprotokolle mit Sicherheitsfunktion zu verstehen?

Warum ich das frage?
Wißt Ihr, mein Nachbar hat da so eine nervtötende Außenbeleuchtung, die er im Rahmen seiner Automatisierung nicht in den Griff kriegt und will mir nicht glauben, dass es besser wäre, meine Lösung zu nehmen! Ich könnte ihm vielleicht ganz heimlich einen klitzekleinen Automatismus von meiner Seite unterschieben und das Problem dadurch lösen, das ist doch erlaubt, oder?

Im Ernst: Danke!
Und für den Fall, dass jemand eine Flasche (na ja, Ihr wißt schon) entbehren kann, vielleicht überlege ich mir, ob ich doch mal beim Grillen jemanden frage, wie ich manche Dinge lösen sollte... Ich würde vielleicht auch die Steaks bezahlen (vielleicht denke ich auch erst mal noch richtig darüber nach, aber wenn, dann nur vom Discounter meiner Wahl!)

Vorher werde ich aber vermutlich noch heimlich mal alte Schullektüre rauskramen, irgendwie will es nicht aus meinem Kopf, dass es eine gute Idee sein könnte, mal wieder den einen oder anderen Dürrenmatt zu lesen. An der Schule fand ich das schwierig und ich habe vermutlich nicht verstanden, was das soll. Vielleicht verstehe ich es ja jetzt, ich bin mir nicht sicher...
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

KölnSolar

ZitatDann sollte es auch kein Problem sein, beliebte Funkprotokolle mit Sicherheitsfunktion zu verstehen?
Naja, das ist dann eher was für die HyperKenner hier  ;) Ich meinte denn mehr die simplen Funkprotokolle wie AC, ARC etc.

ZitatWie in der Theorie die Protokolle und die Kommunikation funktionieren finde ich in diesem Umfang etwas zu theoretisch.
Versteh ich. Verdammt langweilig als Lektüre, auch als Video, gääääääähn. Was ich aber damit sagen wollte: Es gibt so ein Grundverständnis, was man VOR dem ersten Hardwarekauf entwickeln sollte, damit man später keinen Hardware-Zoo hat(oder zumindest nur einen kleinen Zoo) und kauft sich direkt dann das Richtige ! Der kleine Zoo macht halt weniger Arbit als der große Zoo. Also einfach nur die Vorwarnung VOR dem Hardwarekauf sich etwas mehr Gedanken über das Endziel(scheiß Wort) zu machen und so etwas wie ein Pflichtenheft mit Pros und Cons zu erstellen. Ja ich weiß, auch langweilig, aber zielführend ;)
Ich fing auf der Fritte an und hab nun den 3. Rpi, anfangs den CUL868, dann nen CUL434 und setze jetzt überwiegend auf den RFXTRX.......
Markus

RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

der-Lolo

Ich schreib mal damit das hier nicht komplett von den funk themen gekappert wird
;D

Ich fand damals beim Einsteigen am schwierigsten das das System schnell wuchs, wichtig wurden da die verschiedenen möglichkeiten der namensgebungen und Devicebezeichnungen. Auch das aufrufen einer kleinen routine in 99_ empfand ich als Meilenstein.

Zu einem gewissen Zeitpunkt sollte man meiner meinung nach über ein produktiv und ein Testsystem verfügen.

Beta-User

Zitat von: KölnSolar am 06 Juni 2016, 19:39:02
...damit man später keinen Hardware-Zoo hat (oder zumindest nur einen kleinen Zoo) und kauft sich direkt dann das Richtige !

Hallo Markus,

DANKE für das Bild mit dem Zoo, das ist super und sehr viel besser als der Gedanke, Interessenten vielleicht zu empfehlen, ein gutes Buch über Gartenpflege als anschaulichen Vergleich zu lesen (na ja, da stehen so Themen drin wie: es macht Arbeit, die Dinge wachsen, man muß im Verlauf der Jahreszeiten die Dinge erledigen, die grad dran sind und so).

Zoo ist sehr viel besser, weil es zum einen den "Garten" beinhaltet (wenn der Zoo jemandem auch optisch gefallen soll jedenfalls) und darin auch Themen wie artgerechte Haltung der einzelnen exotischen Tiere vorkommen, Und: jemand muß das Kassenhäuschen am Eingang besetzten, die Buchhaltung machen und den "Müll" rausbringen, denn die Elefanten wollen ja nicht nur gefüttert werden, es kommt hinten ja auch was raus... ;)

Vielleicht könnte der TE ein "Video 0" machen, in dem er unbedarften Nutzern eines seltsamen OS erklärt, das FHEM etwas ähnliches ist wie ein Zoo und man lernen sollte, wie man einen Zoo leitet oder es lassen, wenn einem das zu viel ist. Das ist schön anschaulich und "normale Leute" können es verstehen? Vielleicht, vielleicht ist es sogar unterhaltsam für den einen oder anderen Fortgeschrittenen. Vielleicht, ich bin mir wirklich nicht so sicher... Aber vielleicht hat jemand auch eine bessere Idee und kann dem TE auch empfehlen, mit wem er sich zusammensetzen kann?
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

irgendsowas


marvin78

Portforwarding ist sehr unsicher (egal in welcher Kombination). Empfohlene vorgehensweise ist VPN oder zumindest Reverse Proxy. Einfaches Portforwarding zu empfehlen ist extrem fahrlässig (Gründe findet man durch eine kurze Recherche in Rudeln)!

Ich finde es ja gut, dass jemand sich die Mühe macht, solche Tutorials zu bauen (auch wenn ich denke, dass Faulheit damit gefördert wird) ABER man sollte sich mit allen Aspekten der behandelten Themen auseinandersetzen, bevor man sie mit solchen Tutorials möglicherweise zu einem "Quasi-Standard" macht.

Benni

Zitat von: haus-automatisierung.com am 09 Juni 2016, 18:08:56
Das Port Forwarding an sich stellt für mich kein Sicherheitsrisiko dar, es kommt einfach nur darauf an, wie gut man den Port/die Applikation absichert. Oder sehe ich das falsch?

Genau darum ging es mir doch! Dass nicht einfach nur erklärt wird, wie man DynDNS und das Port-Forwarding einrichtet. Das Forwarding an sich ist nicht das Problem sondern, dass dahinter weiter abgesichert werden muss, eben mindestens mit Basic Auth (was nur ein sehr schwacher Schutz ist) und mit Reverse-Proxy und idealerweise auch noch mit SSL. Von daher meinte ich auch, dass das quasi untrennbar zusammengehört.
FHEM ist "out-of-the-box" ja erst mal gar nicht abgesichert.


fiedel

#12
ZitatDas Port Forwarding an sich stellt für mich kein Sicherheitsrisiko dar, es kommt einfach nur darauf an, wie gut man den Port/die Applikation absichert. Oder sehe ich das falsch?
Selbst wenn ich einen Reverse-Proxy einsetzen möchte, komme ich ohne Port-Forwarding doch gar nicht aus?
Genau so ist es.
Zitat... dass dahinter weiter abgesichert werden muss, eben mindestens mit Basic Auth (was nur ein sehr schwacher Schutz ist)
Was mich interessieren würde: Was wäre an FHEM mit BasicAuth + SSL unsicherer, als NGINX mit seinem Auth_Basic - Modul + SSL  oder PAM + SSL (Anmeldung der bestehenden Linuxbenutzer)? Mit PAM kann man dann die Rechte der angemeldeten Benutzer noch variieren, aber hier geht es ja vorrangig um eine möglichst unknackbare Zugangssperre.

Edit: Hier schon mal die Nachteile von BasicAuth.
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

Black7king

wie wäre es den mit einen Video wie man es zb. mit KNX verbindet?
oder wie man vorgeht wenn was nicht so klappt wie es soll.....

TWART016

TelegramBot als Whatapp-Ersatz wäre nicht schlecht. Yowsup scheint nicht mehr zuverlässig zu funktionieren.