Lehrprojekt mit FHEM und HomeMaticIP

Begonnen von Noran, 25 Mai 2018, 12:31:40

Vorheriges Thema - Nächstes Thema

Noran

Hallo liebe FHEM-ler,
im März haben wir begonnen FHEM bei uns an der Professur zu nutzen. Es ist zentrale Komponente für einen sogenannten digitalen Zwilling:
https://www.uni-weimar.de/de/bauingenieurwesen/professuren/intelligentes-technisches-design/lehre/digitaler-itd-zwilling/

FHEM dient dabei als Schnittstelle zu weiteren Elementen wie AR, VR, Simulationsumgebungen etc.

Für eine Konferenz im September ist eine Veröffentlichung geplant.

Die Korrespondenzen mit einer ersten Studentin laufen.

Ich hoffe bald kann ich mehr Details liefern.

Prof. Dr. Peter Henning

Wird bei mir auch in der Lehre eingesetzt.

LG

pah

ext23

Wenn ich da schon überall "TELNET" lese stößt es mir bitter auf als Sec Typ. Da hilft auch nicht die Aussage, dass es nur lokal ist...

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Prof. Dr. Peter Henning

@ext23: Didaktische Anforderungen hebeln auch an anderer Stelle Sicherheitsfragen aus.

LG

pah

Noran

@ ext23: Ich bin immer offen für Kritik. Vielleicht habe sie einen konstruktiven Vorschlag? Ich bin leider bei dem Thema Sicherheit nur Rudimentär bewandert. Mir schwebt auch eine Erweiterung von FHEM vor um die Sicherheit da zu verbessern. Von anderer Software kenne ich es zum Beispiel nur bestimmte IP-Adressen für Verbindungen zuzulassen. Ein weiterer Gedanke ist Verschlüsselungen direkt in FHEM  zu implementieren.

Mein Eindruck bisher ist, dass FHEM nicht so sehr auf Sicherheit an den Schnittstellen ausgelegt ist. Das sieht man auch bei der Verwendung der CUL's. Das ist doch auch unverschlüsselt oder irre ich mich?

Ansonsten wird im Moment ein App für Handy/Tablet entwickelt um eine erste Darstellung der Graphen zu realisieren.

Gruß Noran

eki

Kleiner Tip bezüglich UI: Es gibt mit FTUI ein ziemlich mächtiges Framework zur Erstellung von HMIs auf HTML Basis (enthält auch ein Widget zum Darstellen von verschiedenen Charts, und bietet auch Möglichkeiten responsive Oberflächen zu erstellen) und ist aus meiner Sicht flexibler als eine native APP.

CoolTux

Zitat von: Noran am 13 Juli 2018, 08:40:14
@ ext23: Ich bin immer offen für Kritik. Vielleicht habe sie einen konstruktiven Vorschlag? Ich bin leider bei dem Thema Sicherheit nur Rudimentär bewandert. Mir schwebt auch eine Erweiterung von FHEM vor um die Sicherheit da zu verbessern. Von anderer Software kenne ich es zum Beispiel nur bestimmte IP-Adressen für Verbindungen zuzulassen. Ein weiterer Gedanke ist Verschlüsselungen direkt in FHEM  zu implementieren.

Mein Eindruck bisher ist, dass FHEM nicht so sehr auf Sicherheit an den Schnittstellen ausgelegt ist. Das sieht man auch bei der Verwendung der CUL's. Das ist doch auch unverschlüsselt oder irre ich mich?

Ansonsten wird im Moment ein App für Handy/Tablet entwickelt um eine erste Darstellung der Graphen zu realisieren.

Gruß Noran

FHEM Telnet kann auch SSL, ausserdem ist es möglich über die allowed Instanz das Attribut allowed_from zu setzen, um nur bestimmte IP Adressen zu zu lassen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Prof. Dr. Peter Henning

Eine "Verschlüsselung direkt in FHEM" halte ich für unsinnig. Alle Sicherheitsaspekte können über die Umgebung realisiert werden, in der FHEM läuft.

LG

pah

Noran

Zitat von: Prof. Dr. Peter Henning am 13 Juli 2018, 10:22:44
Eine "Verschlüsselung direkt in FHEM" halte ich für unsinnig. Alle Sicherheitsaspekte können über die Umgebung realisiert werden, in der FHEM läuft.

LG

pah

Können sie mir da vielleicht noch andere Stichworte außer SSH nennen?

Mit freundlichen Grüßen
Noran

ext23

Zitat von: CoolTux am 13 Juli 2018, 09:15:35
ausserdem ist es möglich über die allowed Instanz das Attribut allowed_from zu setzen, um nur bestimmte IP Adressen zu zu lassen.

Das ist imho Blödsinn, das entspricht keiner Verschlüsselung und ist im Prinzip derselbe Blödsinn wie ein MAC Filter im WLAN Netz. Unbrauchbar und maximal so viel Wert wie ein vereister Schließzylinder...

Zitat von: Noran am 13 Juli 2018, 08:40:14
Mein Eindruck bisher ist, dass FHEM nicht so sehr auf Sicherheit an den Schnittstellen ausgelegt ist. Das sieht man auch bei der Verwendung der CUL's. Das ist doch auch unverschlüsselt oder irre ich mich?

Richtig, nun muss mal schauen ob der CUL via USB angebunden ist oder via LAN. Sicherlich kann man alles in einem eigenen (V)LAN betreiben. Aber in der heutigen Zeit, wo Verschlüsselung auf so gut wie jedem µC ohne große Sprünge läuft ist es nicht Wert auch nur ein Augenzwinkern daran zu verschwenden mit unverschlüsselten Protokollen zu arbeiten.

Und genau weil sich viele keine Gedanken machen auch mangels Kompetenz haben wir heute Kraftwerke die mit SCADA Systeme Arbeiten die offen sind wie die nächste Dorfkirche und Autos die anfällig gegen jegliche Replay Attacke sind um sie zu öffnen... Nur mal als Beispiel...

Es ist schwer nachzuvollziehen in einer Zeit wo die Runden Ecken an Buttons wichtiger sind als Sicherheit. Solange alles läuft, kein Thema, so lange alles läuft stört mich auch ein AKW umde Ecke nicht... Solange nicht jemand die angeblich so gut verschlüsselten WhatsApp Nachrichten mitlist wo der Key auf irgend welchen Server liegt damit das Restore beim neuen Handy auch schön einfach ist, alles kein Thema...

Gut wie dem auch sei, ich kann da nicht weiter helfen. Das ist ein Thema in welches man sich reinarbeiten muss. Aber es ist für jedermann sicher vom Vorteil das immer im Hinterkopf zu haben, genau so wie man immer dran denkt die Tür hinter sich abzusperren. ;-)

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

JoWiemann

Ersten
Pauschal von ungesicherten SCADA Systemen zu reden von denen man keine Ahnung hat und auch nur in der Presse gelesen hat ist Blödsinn.

Zweitens
Alle Systeme sind so sicher, wie der, der vor dem Bildschirm sitzt, es zulässt.

Drittens
Sicherheit ist immer Aufwand. Und das fängt beim Wissen an.

Viertens
Erst nach einer fundierten Risikoabschätzung kann ich, oder ein wissender Beauftragter, eine fundierte Aussage machen.

Fünftens
Nicht alles, was preiswert zu haben ist sicher. Sicherheit kosten. Sichere Smarte Komponenten sind teuer. Ob aber jeder Aktor oder jeder Sensor hoch verschlüsselt angesprochen werden muss, zeigt die Risikoanalyse.

Sechstens
Fhem ist so sicher, wie ich es mache. Da es offen ist kann jeder es sicherer machen.

Aber es ist wie immer...


Gesendet von iPhone mit Tapatalk

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

Noran

Ich kann den Unmut und die Diskussion um das Thema Sicherheit gut verstehen. Mein ehemaliger Chef hat einen Spruch gehabt den er immer gerne brachte: "Wir brauchen nicht noch mehr Probleme, sondern Lösungen dazu." Mittlerweile verstehe ich diesen Spruch als Zusammenfassung von Lösungsorientiertem Arbeiten. Dementsprechend wäre es interessanter für mich, wenn an dieser Stelle Vorschläge zu Umsetzung oder Literaturhinweise gegeben würden, anstatt über Sicherheit von Kernkraftwerken zu diskutieren.

Ansonsten denke ich gibt es im August/September neues in dem Projekt. Hoffentlich dann die mobile-App - wobei das Webtool nicht außer acht gelassen werden soll, danke dafür.

Mit freundliche Grüßen
Noran

Amenophis86

Lösung: Suchfunktion im Forum. Dort finden sich einige Vorschläge zur Sicherheit :)
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Prof. Dr. Peter Henning

Alle Sicherheitsaspekte sind im Forum schon behandelt worden.

Es ist sicher auch nicht Aufgabe des Forums, Literaturangaben für studentische Projekte zu liefern. Die Sicherheitsproblematik besteht nämlich - und in sofern ist die Diskussion über die Sicherheit von Kernkraftwerken vollkommen richtig - unabhängig vom Einsatzzweck.

Mein Tipp daher: Einfach mal selbst recherchieren. Eine Google-Suche mit den Stichworten "Sicherheit Raspberry Pi" liefert nicht umsonst 149 Millionen Hits. Etwas weniger, wenn man wirklich Fachliteratur sucht, nur 3,85 Millionen Hits. Aber da wird schon etwas dabei sein.

LG

pah

JoWiemann

Hm, die Diskussion um Sicherheit in der IT wird leider nur technologisch und nicht Verhaltensorientiert geführt.

Wir haben in in dem Unternehmen in dem ich tätig bin etwa zehn Jahre gebraucht um die Einstellung und das Verhalten in der Arbeitssicherheit grundlegend zu verändert. Heute akzeptiert jeder, das Unfälle nicht geschehen sondern verursacht werden. Das man der Ursache nur auf den Grund gehen kann, wenn auch die nebensächlichsten Unfälle oder Beinahunfälle gemeldet werden und dass das Befolgen von Regeln zur Arbeitssicherheit das Wichtigste ist.

Für die Sicherheit gerade in der Softwareentwicklung findet dieses Umdenken gerade statt. Das heißt nicht das es nicht bereits Regeln gibt. Aber die gab es damals in der Arbeitssicherheit auch und wir hatten trotzdem zu viele Unfälle. Wie geschrieben. Die Haltung muss sich ändern. Software muss nicht nur gut aussehen, am Besten noch funktionieren, sondern grundsätzlich sicher sein.


Gesendet von iPhone mit Tapatalk

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

Prof. Dr. Peter Henning

#15
Dem kann ich nicht zustimmen: Die Diskussion wird durchaus verhaltensorientiert geführt - nur nicht von allen. Ich habe zusammen mit Anderen schon Mitte der 90er Jahre Verhaltensfragen in ein Sicherheitskonzept der Deutschen Börse eingebracht.

Allerdings weigerten sich schon damals die so genannten Entscheider, ihr Verhalten zu ändern und sahen in der Informatik nur Mittel zur Unterstützung ihrer festgefügten Weltanschauung.
Das geht bis heute so weiter - gerade die ZEIT von vorgestern führt mir dies wieder vor Augen. Da fordert doch eine namhafte deutsche Unternehmerin, die auch Mitglied des Wissenschaftsrates war und selbst Literaturwissenschaftlerin ist, dass jedes Schulkind "programmieren" lernen solle - das würde die Wirtschaft brauchen.

Nun bin ich wirklich einer derjenigen, der das Thema "Informatik im Schulunterricht" (eben nicht "programmieren") seit Jahren vorantreibt - aber es schüttelt mich, wenn ich dann erlebe, wie die so genannten Entscheider daraus  wieder einen Technikunterricht zum Nutzen der Wirtschaft machen. So lange "Techies" als nützliche (mietbare) Zwerge gelten, wird das auch nicht anders werden.

LG

pah

dev0

ZitatSo lange "Techies" als nützliche (mietbare) Zwerge gelten, wird das auch nicht anders werden.
Das kann ich, als Freelancer in der IT (30+ Jahre), gar nicht genug unterstreichen. Leider.

Prof. Dr. Peter Henning

Wir können alle nur unser Bestes geben, die Mentalität zu ändern. Ich habe Anfang November auf einer Konferenz im ZKM eine Keynote zu der Frage gehalten, wer denn eigentlich in der digitalen Welt der "Feind" ist. Kann man hier ansehen: https://zkm.de/de/person/peter-a-henning

LG

pah

ext23

#18
Und als Informationsquelle für Interessierte: Mal den CISSP machen, als Anfang immer gut...

Zumindest hierfür "Hm, die Diskussion um Sicherheit in der IT wird leider nur technologisch und nicht Verhaltensorientiert geführt."

Technisch ist wie gesagt alles einfach, es reicht nur bei vielen nicht im Kopf, das ist das große Problem... Es reicht bei vielen nicht mal mehr den Schalter umzulegen der auch noch da ist und rot blinkt.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Noran

Von Mittwoch bis heute läuft das Forum Bauinformatik. Dort habe ich das System einmal vorgestellt. Wer Interesse hat, kann sich gerne den Beitrag online ansehen: https://doi.org/10.25643/bauhaus-universitaet. Seite 121 bis 128.

Liebe Grüße
Noran

Morgennebel

ZitatAls problematisch stellte sich die Handhabung von FHEM dar. Die Weboberfläche ist für Spezialisten gestaltet und arbeitet mit Befehlen zum Einrichten von neuen Modulen und ändern der Paramter. Eine intuitive Bedienung ist demnach kaum möglich. So müssen z.B. Regeln für zeitgesteuerte Events per Kommandozeile definiert werden.

Mir graust vor einer Lehre für zukünftige Ingenieure, die an einer Befehlszeile scheitern. Das ist die Grundlage für ein weiteres BER, Stuttgart 21 und eine Elbphilharmonie...

Ciao, -MN
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

CoolTux

S. 125
Zitat
FHEM  ist  nicht  in  der  Lage  direkt  über  den Transceiver  mit  den  Smart-Home-Elementen  von  HomeMatic  IP  zu  kommunizieren.  Dies liegt an dem eigens entwickelten Kommunikationsprotokoll der Marke (FHEM E.V. 2017).

Ich verstehe das so das das "eigens entwickelten Kommunikationsprotokoll" von FHEM ist. Dem ist aber nicht so, es ist hier sicherlich Homematic gemeint.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

connormcl

Zitat von: CoolTux am 21 September 2018, 14:57:49
S. 125
Ich verstehe das so das das "eigens entwickelten Kommunikationsprotokoll" von FHEM ist. Dem ist aber nicht so, es ist hier sicherlich Homematic gemeint.

Nein, das ist ein Zitierhinweis. Im Literaturverzeichnis steht dabei ein Verweis auf das FHEM Forum:

FHEM E.V. (2017),
www.forum.fhem.de/index.php/topic,83376.msg756115.html#msg756115
(21.07.2018).

Allerdings ist der Link falsch und existiert so nicht...

Und generell finde ich die Entscheidungsbegründungen im Artikel aus wissenschaftlicher Sicht zumindest fragwürdig... dort werden z.B. Komponenten genommen, weil sie "einfacher zu installieren" oder nicht genommen, weil "das Fortschreiten der Entwicklung" nicht absehbar ist (was es dann bei der ausgewählten Komponente auch nicht ist).
Genauso wurde die Auswahl von FHEM begründet: Quelloffen und viele Schnittstellen. Da fallen mir aus dem Stand mindestens drei weitere Systeme ein, die das bieten... hätte man vergleichen können... auch wenn man sich nachher über angebliche Unzulänglichkeiten bei FHEM beschwert, die nur deshalb unzulänglich sind, weil man das System noch nicht vollständig begriffen hat...

Prof. Dr. Peter Henning

#23
Meine Güte, welch ein Unsinn. Diese Fakultät scheint irgendwelchen halbfertigen Studierenden Vorträge zu geben und das als "Wissenschaft" zu verkaufen. Ich werde dem mal nachgehen und versuchen, die Qualität etwas zu heben...

LG

pah

Wernieman

OT:

pah:
Kann es nicht woanders schreiben, deshalb hier: Danke für den Link auf Deine KeyNode
- 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

Noran

@ Morgennebel: Ingenieure im Bauwesen sind keine Elektroingenieure oder ähnliches. Sie sind Fachmänner für Statik und Bauwerksphysik. Ein Großteil arbeitet mit Excel oder Fachspezifischer Software für Berechnungen, wobei mit grafischen Benutzeroberflächen gearbeitet wird. Kommandozeilen sind für viele weit entfernt. Bei Architekten sieht es ähnlich aus (auch diese dürfen sich offiziell als Ingenieur bezeichnen.

@CoolTux: Dieses Missverständnis tut mir leid. Zentraler Punkt dort ist, dass FHEM nicht direkt mit HomeMatic-Komponenten kommunizieren kann. Es muss immer eine CCU (physisch oder virtuell) zwischen geschaltet werden. Wenn die Kommunikation ohne eine CCU funktionieren würde, wäre das ein Fortschritt.

@connorcml: Eine weitere Software wurde genannt: openHAB. Leider war als maximale Länge 8 Seiten vorgegeben. Da der Fokus auf einer Möglichkeit der Umsetzung lag und nicht auf dem Vergleich unterschiedlicher Software, wurden keine weiteren Begründungen für die Auswahl angeführt. openHAB und FHEM bleiben als gleichwertig stehen. Ich würde mich freuen zu hören, wo ich Wissenslücken in FHEM habe. Welche Unzulänglichkeiten beruhen auf Unverständnis?

Prof. Dr. Peter Henning

#26
ZitatWenn die Kommunikation ohne eine CCU funktionieren würde, wäre das ein Fortschritt.

Prima. Dieser "Fortschritt" existiert in Bezug auf HomeMatic seit mindestens 5 Jahren und ist bestens dokumentiert. Dass dies mit HomeMaticIP nur unter Verwendung des Hersteller-eigenen Gateways funktioniert, ist, neutral ausgedrückt, Politik des Herstellers.

Schlussfolgerung: Leider wurde der "Artikel" sehr schlecht recherchiert. Bestätigt meine Einschätzung von oben - das ist echt Schund.

LG

pah

CoolTux

Zitat von: Prof. Dr. Peter Henning am 22 Oktober 2018, 14:22:46
Prima. Dieser "Fortschritt" existiert seit mindestens 5 Jahren und ist bestens dokumentiert.

Schlussfolgerung: Leider wurde der "Artikel" sehr schlecht recherchiert. Bestätigt meine Einschätzung von oben - das ist echt Schund.

LG

pah

Pah hast Du die Randbedingung bei Deiner Aussage beachtet "Lehrprojekt mit FHEM und HomeMaticIP"


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Morgennebel

Zitat von: Noran am 22 Oktober 2018, 13:53:52
@ Morgennebel: Ingenieure im Bauwesen sind keine Elektroingenieure oder ähnliches. Sie sind Fachmänner für Statik und Bauwerksphysik. Ein Großteil arbeitet mit Excel oder Fachspezifischer Software für Berechnungen, wobei mit grafischen Benutzeroberflächen gearbeitet wird. Kommandozeilen sind für viele weit entfernt. Bei Architekten sieht es ähnlich aus (auch diese dürfen sich offiziell als Ingenieur bezeichnen.

Vielleicht ist mein Verständnis an universitäre Lehre und Methoden anders als Deines?

Ich erwarte von einer Universität, daß sie die Methoden und Strukturen lehrt und vermittelt. Die Werkzeuge dazu sind nebensächlich - Excel, Befehlszeile, PHP, bash - egal. Solange die Strukturen verstanden wurden, läßt sich das alles irgendwie realisieren.

Eine Universität, die sich auf die Werkzeuge beschränkt, beschneidet notwendigerweise das Vermitteln der Strukturen und Methoden. Dann verkommen die Statiker zu Datentypisten, ohne zu wissen, was sie da eigentlich tun...

Wo bleibt dann die Forschung, die Weiterentwicklung, die Innovation, wenn alle "Ingenieure" nur stumpf Zahlen in Bildschirmmasken hämmern?

Ciao, -MN
Einziger Spender an FHEM e.V. mit Dauerauftrag seit >= 24 Monaten

FHEM: MacMini/ESXi, 2-3 FHEM Instanzen produktiv
In-Use: STELLMOTOR, VALVES, PWM-PWMR, Xiaomi, Allergy, Proplanta, UWZ, MQTT,  Homematic, Luftsensor.info, ESP8266, ESERA

Prof. Dr. Peter Henning

@CoolTux: Du hast Recht, das hätte man präziser formulieren müssen. Siehe oben.

@Morgennebel:
ZitatIch erwarte von einer Universität, daß sie die Methoden und Strukturen lehrt und vermittelt
Lass mal bitte das "Universität" weg. Wir sagen deshalb "Hochschule", weil dieser Anspruch auch an den Hochschulen für Angewandte Wissenschaften - ehemals Fachhochschulen - besteht. Wir grenzen uns aber bewusst von den Universitäten ab.

ZitatWo bleibt dann die Forschung, die Weiterentwicklung, die Innovation, wenn alle "Ingenieure" nur stumpf Zahlen in Bildschirmmasken hämmern?
Einer der Gründe für die Abgrenzung ist, dass an manchen (nicht allen) Universitäten genau dies passiert. Es wird Mickymaus-Wissenschaft betrieben.

LG

pah

Chris74

Hallo,

auch an Hochschulen besteht ein gewisser wissenschaftlicher Anspruch. Anwendungsorientierte Wissenschaft ist gerade in dem Bereich die Zukunft schlechthin.

LG Chris

Prof. Dr. Peter Henning

Wenn man schon alte Threads wieder aufmacht, sollte man genauer lesen. "Hochschulen" ist der Oberbegriff.

LG

pah