FHEMWEB komplett abschalten und durch apache2 ersetzen?

[sven.luebke]

Hallo FHEM-Community!

Ich frage mich, ob es möglich und sinnvoll ist, FHEMWEB komplett abzuschalten und durch apache2 zu ersetzen. Bisher habe ich vermutl. immer nur Anleitungen gefunden, in der apache als ReverseProxy zwecks höherer Sicherheit genutzt wurde. Bin noch nicht so lange FHEM-Nutzer und hoffe, dass ich für die Frage nicht gesteinigt werde.

Danke Euch für Eure Antworten!

[JoWiemann]

Hm, eigentlich möchtest Du die WebServer Komponente durch einen Apache2 ersetzen. Das FhemWeb ist aber ein Modul, dass die HTML Seiten generiert und an den WebServer von Fhem ausliefert. Es gibt ja schon einige Lösungen, die nicht FhemWeb benutzen, sondern eigene Webseiten, über dann auch andere WebServer ausliefern.

Eine aktuelle Lösung ist die FhemApp.

Grüße Jörg

[sven.luebke]

Ja, genau das möchte ich machen. Deiner Beschreibung nach ist FHEMWEB also nicht nur der Webserver, sondern auch für die Generierung der Webseiten zuständig. Dadurch macht meine Frage also nicht mehr so richtig Sinn. Wie Du schon schreibst würde ich also vielmehr gerne den FHEM-Webserver abschalten. Es klingt aber so, als wäre diese Komponente nicht mal so eben per Config von dem Rest zu trennen.

[justme1968]

bitte nicht falsch verstehen... aber warum möchtest du das? wie kommt man auf so eine idee?

wenn man apache so wenig kennt das man so eine frage stellt sollte man die finger davon lassen. genauso von den ganze reverse proxy ideen. ohne sich wirklich damit auszukennen erhöhen man nicht die sicherheit sondern schafft neue baustellen und fehlerquellen. mal ganz abgesehen davon das man fhem schlicht und einfach nicht ins internet freigeben sollte. ganz egal auf welche art. das ist einfach der falsche ansatz.

wenn man von außen zugreifen will ist ein vpn einfacher, sicherer und auch für anfänger geeignet. es gibt (fast) keinen grund sich nicht damit zu befassen. zumal es noch viele andere dinge ermöglicht.

oder ein dialog mit telegram, einbinden in siri oder alexa aber um himmels willen nicht direkt freigeben.

oder falls es um ein unsicheres lokales netz geht: zum einen hast du dann noch sehr viel mehr probleme die nicht mit fhem zu tun haben und zum anderen sollte man das ganze dann erst mal auf netzwerk ebene z.b. über vlans absichern.

ps: ich weiss du hast nichts von freigeben gesagt, aber ich kann mir gerade keinen anderen hintergrund vorstellen.

pps: natürlich kann man fhemwb komplett deaktivieren. aber auch das mach nur sehr begrenzt sinn.

[sven.luebke]

Stimmt, ich hatte vor, meinen Hintergrund zu verschweigen mit der Befürchtung, dass man es mir ausreden möchte  . Ich lasse FHEM auf einer Fritzbox 7490 laufen und habe das Problem, das hier auch schon öfter erwähnt wurde...aber scheinbar nicht so richtig gelöst. FHEM läuft ohne Probleme im Hintergrund...bis ich die FHEM-Webseite öffne. Laut strace bleibt perl bei _newselect() einfach stehen und macht absolut NICHTS mehr. Ich kann das Problem leider totsicher zu 100% nachstellen. Config-Änderungen bringen auch keine Verbesserung. Erst schien es mir ein RAM-Problem zu sein, aber selbst bei 35MB freiem Speicher tritt es auf. Nach weiterer Forschung scheint es so zu sein, dass nach der Übertragung von www/pgm2/jquery-ui.min.js ALLES still steht. Jetzt hab ich mal versucht diese Datei umzubenennen und meine FHEM-Weboberfläche läuft wunderbar...sogar eigentlich schneller als vorher. Ich vermute mal, dass die Datei vielleicht zu groß ist und es dadurch zu Problemen kommt.

Es gibt hier im Forum auch schon ein paar andere Einträge, aber eine Lösung habe ich noch nicht gefunden. Weil mein apache2 aber seit Jahren "sicher" auf der Fritzbox 7490 läuft (ja, auch von außerhalb erreichbar), wollte ich wissen, ob ich dieses Problem einfach durch den apache2 umgehen kann.

[JoWiemann]

Ja, genau das möchte ich machen. Deiner Beschreibung nach ist FHEMWEB also nicht nur der Webserver, sondern auch für die Generierung der Webseiten zuständig. Dadurch macht meine Frage also nicht mehr so richtig Sinn. Wie Du schon schreibst würde ich also vielmehr gerne den FHEM-Webserver abschalten. Es klingt aber so, als wäre diese Komponente nicht mal so eben per Config von dem Rest zu trennen.

Sieh es mal so. FhemWeb dient primär der Administration von Fhem. Für die Visualisierung gibt es mittlerweile viele hervorragende Lösungen. Sofern Du FhemWeb nicht mehr möchtest müsstest Du die komplette Administration neu entwickeln. Kann man machen, muss man aber nicht. "Abschalten" kannst Du FhemWeb, wenn Du das Device web, oder wie auch immer es bei Dir heißt, löschst. Dann brauchst Du aber eine Administrationsalternative.

Grüße Jörg

[sven.luebke]

Sofern Du FhemWeb nicht mehr möchtest müsstest Du die komplette Administration neu entwickeln. Kann man machen, muss man aber nicht. "Abschalten" kannst Du FhemWeb, wenn Du das Device web, oder wie auch immer es bei Dir heißt, löschst. Dann brauchst Du aber eine Administrationsalternative.

Das ist genau die Antwort, die ich vermutet, aber noch nicht gefunden hatte. Eine Administrationsalternative möchte ich nicht entwickeln, also ist das Abschalten keine Lösung! Ich muss also eher mein obiges Problem lösen...

Danke Dir!

[marvin78]

Ein Raspi statt FB!?

[sven.luebke]

Ein Raspi statt FB!?

Ja, könnte funktionieren. Mich interessiert aber, warum es hier zu einem Problem kommt. "jquery-ui.min.js" ist 234KB groß...Plots und alles andere geht wunderbar schnell und ohne Probleme...wenn die Datei nicht gefunden werden kann  .

[Frank_Huber]

Ein Raspi statt FB!?

+1

Dann kannst auch deine Fritte wieder updaten... die fährt ja jetzt auch ein veraltetes OS, oder?

[rudolfkoenig]

Klar kann man FHEMWEB abschalten (d.h. in fhem.cfg nicht definieren), neben den HTML Seiten fuer Konfiguration/etc hat man aber auch kein HTML- oder WebService API mehr zur Verfuegung, und etliche Alterntiv-Frontends setzen darauf.
Konfigurieren kann man FHEM weiterhin vollstaendig via telnet

Off-Topic:
Ironie des Schicksals: FHEMWEB ist entstanden, weil mir apache auf dem Fritzbox zu gross erschien.
Ich wusste schon, dass eine ernsthafte Wiederbelebung von FHEM @ Fritzbox zu viel Ressourcen bindet, auch hier im Forum. Bei der naechsten Frage werde ich einfach behaupten, das geht gar nicht

[sven.luebke]

+1

Dann kannst auch deine Fritte wieder updaten... die fährt ja jetzt auch ein veraltetes OS, oder?

Nein, es ist alles aktuell, also Fritz!OS 7.21 . Das im Internet verfügbare FHEM-Archiv läuft natürlich nicht mehr. Ich hab es selber durchgebaut...

[sven.luebke]

Off-Topic:
Ironie des Schicksals: FHEMWEB ist entstanden, weil mir apache auf dem Fritzbox zu gross erschien.
Ich wusste schon, dass eine ernsthafte Wiederbelebung von FHEM @ Fritzbox zu viel Ressourcen bindet, auch hier im Forum. Bei der naechsten Frage werde ich einfach behaupten, das geht gar nicht

apache2 lief zwar inkl. PHP und Subversion auch auf meiner 7270 mit 64MB RAM...aber mit FHEM wäre das System sicherlich überlastet gewesen...da hast Du schon richtig gehandelt! Mit dem 4-fachen RAM fällt der verfügbare Speicher seit 2013 deutlich komfortabler aus.

Aber vielleicht reicht der RAM ja wirklich nicht. Ich werde zum Spaß mal 512MB swap einbinden. Mal gucken, ob das etwas ändert. Dann weiß ich zumindest, dass die Fritzbox wirklich keine gute Idee mehr für FHEM ist.

[rudolfkoenig]

Wenn wir bei der Geschichte sind: FHEM+FHEMWEB lief auch auf der FB7170, allerdings war der Feature-Umfang deutlich kleiner.
Ausser FHEM und FB-Grundfunktionen lief da nichts (auch kein gnuplot, deswegen entstand das SVG Modul), und die Menge der FHEM-Geraete war uebersichtlich. Damals habe ich auf minimalen Speicherbedarf geachtet, das ist in den letzten 5+ Jahren nicht mehr der Fall gewesen.

[sven.luebke]

Ja, das glaub ich Dir. Und dass man dann irgendwann nicht mehr auf den Speicher achten kann, ist auch klar. Da hast Du echt etwas Schönes entwickelt! Vielen Dank dafür!

Ich glaube, ich habe mein Problem gerade gefunden: Das Umbenennen der jquery-Datei war natürlich keine Lösung, die benötigt man ja früher oder später. Das Anlegen und Einbinden einer swap-Datei, so dass sie unter "free" gelistet ist, hat aber bei meinem Problem auch nicht geholfen. Der Speicher wird nicht genutzt. Falls swap-Speicher ansonsten automatisch vom Kernel benutzt wird, war das auf jeden Fall keine Abhilfe für mein Problem. Hätte mich auch sehr gewundert, da selbst VmHWM für den perl-Prozess bei mir relativ konstant blieb...

Dann hab ich mir mal die TCP-Socket-Sizes angeschaut und mittels perl auf 262KB erhöht. Nun tritt mein Problem nicht mehr auf...und die responsiveness der Seite hat sich auch merklich verbessert. Bevor ich anfange zu jubeln, werde ich erstmal abwarten und das System ein paar Tage laufen lassen. Ich hätte vorher öfter das Gefühl (anhand von netstat-Ausgaben), dass manche Ports zur mysql-Datenbank nicht mehr dicht gemacht werden. Schauen wir mal!

Nachdem ich jetzt nochmal mitbekommen habe, dass das Thema FHEM@Fritzbox nicht mehr gerne gelesen wird, werde ich hoffentlich nichts mehr dazu schreiben.

Danke für Eure Kommentare!

[JoWiemann]

Nachdem ich jetzt nochmal mitbekommen habe, dass das Thema FHEM@Fritzbox nicht mehr gerne gelesen wird, werde ich hoffentlich nichts mehr dazu schreiben.

Hm, das ist nur gefühlt so. Ist so ähnlich, wie Fhem unter Windows. Bei einem entsprechenden Post schauen alle erst einmal verdutzt und reagieren dann mit: Ach du schei... Mach doch so etwas nicht. Aber ich glaube, am ende wird immer irgendwie eine Lösung gefunden.

Grüße Jörg

[sven.luebke]

Hm, das ist nur gefühlt so. Ist so ähnlich, wie Fhem unter Windows. Bei einem entsprechenden Post schauen alle erst einmal verdutzt und reagieren dann mit: Ach du schei...

Dann ist ja gut . Ich hatte schon ein schlechtes Gewissen...gerade nach dem Kommentar von Rudolf 

Ich habe bei der Abfrage der TCP-Socket Buffersize noch etwas Interessantes gefunden. Der Text "The default..." gibt immer an, welche Socket-Buffersize als Default konfiguriert war. Im ersten Fall also 23720 für Send. Ich vergrößere den Wert dann auf 262KB . Später scheint der Wert sogar auf 664070 geändert worden zu sein. Dann wieder zurück auf den ersten Wert. Erklären kann ich mir das nicht...es sei denn perl oder FHEM macht das noch irgendwo anders. Vielleicht ist das der Grund, warum der Aufruf der FHEM-Seite manchmal funktionierte und ganz oft nicht. Jetzt ist die Geschwindigkeit MEHR als perfekt für mich: Das Anzeigen des Logfiles hat vorher manchmal so ca. 5s gedauert. Jetzt dauert es keine Sekunde mehr.

Code Auswählen Erweitern

The default sndsize = 23720
The default rcvsize = 87380
The modified sndsize = 262144
The modified recvsize = 262144
TcpServer_WriteBlocking
TcpServer_Wait
Socket geöffnet!
TcpServer_Close
TcpServer_Close
TcpServer_Close
TcpServer_Accept
The default sndsize = 664070
The default rcvsize = 262094
The modified sndsize = 262144
The modified recvsize = 262144
TcpServer_Close
TcpServer_Close
TcpServer_Close
TcpServer_Close
TcpServer_Close
TcpServer_Close
TcpServer_Close
TcpServer_Close
TcpServer_Close
TcpServer_Accept
The default sndsize = 664070
The default rcvsize = 262094
The modified sndsize = 262144
The modified recvsize = 262144
TcpServer_Close
TcpServer_Accept
The default sndsize = 23720
The default rcvsize = 87380
The modified sndsize = 262144
The modified recvsize = 262144
TcpServer_Accept
The default sndsize = 23720
The default rcvsize = 87380
The modified sndsize = 262144

[Frank_Huber]

Nein, es ist alles aktuell, also Fritz!OS 7.21 .

Es war aktuell. Heute kam die 7.26 raus. https://avm.de/service/downloads/?product=fritzbox-7490

[sven.luebke]

Hallo, ich mal wieder!

Ich hab mir nun extra etwas Zeit gelassen, um die Fritzbox und FHEM intensiv zu testen. Ich kann nach einer 3-monatigen Testphase nun sagen, dass ich mit der gesamten Geschwindigkeit zu 95% SEHR zufrieden bin und ich bin hinsichtlich des Themas "Webseiten anschauen" schnell sehr ungeduldig. Es gibt allerdings wirklich ein paar Aktionen, die man in FHEM auf der Fritzbox nicht unbedingt so oft machen sollte

• updates und dann erwarten, dass man in 30s weiter "arbeiten" kann:
  2021.07.13 17:30:53 1 : Calling /var/media/ftp/usr/bin/perl /var/media/ftp/opt/fhem/contrib/commandref_join.pl -noWarnings, this may take a while
  2021.07.13 17:36:47 1 :
  Wie man sieht, dauert die Aktion 6min.
• Select icon oder Extend devStateIcon sollte man auch nicht anwählen. Danach ist das System lange beschäftigt. SVG Plots klappen wunderbar und dauern 4-10s (je nach Grafikumfang)

Weil ich gerade viel beschäftigt war (und bin), hatte ich für 1035,4h gerade keine Zeit für FHEM. Ein Klick und die Seite öffnet sich, keine Verzögerungen und der VmHWM-Wert liegt bei 52MB.
Man muss dazu sagen, dass ich kein Haus habe, sondern nur eine Wohnung. Die vernetzten Geräte halten sich also im Rahmen. Tasmota (inkl. MQTT), direkt angeschlossenem MapleCUL (mit einem 433 und 868MHZ-Modul) sowie haufenweise angemeldeten Rauchmeldern, Heizkostenverteilern und Temperatur-Modulen.

Mit der Standard-Einstellung der Fritzbox hat man allerdings wirklich wenig Spaß, weil sich FHEM scheinbar dauernd aufhängen kann (das war der eigentliche Grund für diesen Thread). Abhilfe hat die Erstellung der Datei sysctl.conf mit folgendem Inhalt gebracht

Code Auswählen Erweitern

net.ipv4.tcp_rmem=32768 262144 1934144
net.ipv4.tcp_wmem=32768 262144 1934144
net.core.optmem_max=20480
net.ipv4.tcp_rmem=32768
net.ipv4.udp_rmem_min=16384
Diese muss man beim Start mittels

Code Auswählen Erweitern

/sbin/sysctl -p $PFAD_ZU_DEN_EINSTELLUNGEN/conf/sysctl/sysctl.conf
laden. Danach ist das System zu 100% stabil und bleibt nicht mehr hängen. Falls jemand FHEM ohne diese Settings testet, dann ist klar, dass man keinen Spaß daran haben kann. Allein das Anzeigen des Logfiles hat vorher ewig gedauert. Jetzt ist es "einfach" da. ICh bin überzeugt davon, dass man mit einer 7590 noch mehr Spaß haben kann...ich war allerdings zu geizig mir deswegen eine zu kaufen. Sehen würde ich es aber schon gerne mal...

Fazit
Fritzbox und FHEM? Immer noch eine klare Empfehlung von mir, wenn man ein bisschen Energie sparen möchte und mit ein paar kleinen Einschränkungen leben kann. Ich muss allerdings auch sagen, dass ich von meinem Pi4 4GB beeindruckt war, der im hochgefahrenen Zustand gerade mal 3,5W gezogen hat.

[rudolfkoenig]

Wie man sieht, dauert die Aktion 6min.

attr global commandref modular

[betateilchen]

attr global commandref modular

Alternativ:

Das globale Attribut exclude_from_update um den Eintrag "commandref" erweitern, dann wird überhaupt keine lokale commandref mehr erzeugt.