Hi zusammen,
ich habe schon die SuFu benutzt und einige Themen durchgelesen. Dabei ging es aber dann meist um ungenügende Geschwindigkeit des System, Hänger etc. und den Umzug der kompletten Installation auf eine leistungsfähigere Hardware (NUC, Mini PC etc)
So ganz passt das nicht zu meinem Anliegen.
Meine FHEM Installation läuft aktuell auf einem Raspberry Pi 3B, ich habe auch noch einen 3B+ hier rumliegen den ich immer mal wieder zum Testen (Shopsysteme, Openhab, IOBroker etc) hergenommen habe. Ein einfaches "Umhängen" der SD Karte aus dem 3B in den 3B+ geht leider nicht, das hatte ich vor einiger Zeit mal getestet und das hatte irgendwie nicht sauber funktioniert.
Hintergrund meiner Frage:
FHEM läuft an sich absolut stabil und auch zufriedenstellend was die Geschwindigkeit im normalen FHEMWeb angeht. Lediglich bei SVG Plots dauert es immer etwas, aber absolut im Rahmen und erträglich.
Ich sitze aktuell endlich an der Visualisierung damit ich mir ein Tablet an die Wand hängen kann um FHEM nach Jahren auch mal "bequem" zu steuern.
Nun ist es aber so, dass die TabletUI (erstelle gerade die Oberfläche mit FUIP) etwas langsam ist.
Je nach Anzahl der Plots dauert es bis zu 10 Sekunden bis alles aufgebaut ist, die Grundstruktur der Seite ist recht schnell da.
Meine Überlegungen waren jetzt:
- Umzug der kompletten FHEM Installation auf eine leistungsfähigere Hardware (NUC, Mini PC etc.). Vorteil: Weiterhin eine zentrale Instanz, Geschwindigkeit hoffentlich deutlich erhöht || Nachteil: viel Aufwand da alles neu installiert und komplett neu programmiert werden müsste, alle Module etc... Möchte ich eigentlich vermeiden
- zusätzliche Instanz FHEM nur für die Visualisierung, dafür könnte ich den Pi 3B+ nutzen, der dümpelt hier aktuell eh nur rum und wird nicht wirklich genutzt. Vorteil: vorhandene Hardware wird genutzt, hoffentlich erhöhte Geschwindigkeit || Nachteil: 2 Instanzen - zusätzlich weiß ich nicht genau wie das umzusetzen wäre. Nutze ich dafür z.B. FHEM2FHEM um das zu spiegeln oder wie wäre das technisch zu realisieren?
- zusätzliche Instanz FHEM auf meiner Synology NAS nur für die Visualisierung. Vorteile: vorhandene Hardware wird genutzt, hoffentlich erhöhte Geschwindigkeit || Nachteil: wie bei zweitem PI, zusätzlich ist bei der Synology durch Docker die Netzwerkfrage nicht ganz trivial
Wie würdet ihr hier vorgehen? Gibt es noch weitere Varianten? z.B. mit apptime erst mal analysieren warum der Pi vielleicht langsamer ist?
Ohne Zugriff über Tablet ist Load bei etwa 0.2, heute beim Arbeiten über FUIP laut Sysmon sogar bei 1.2
Grüße
Panger
Hi zusammen,
von meiner Seite noch ein kurzes Update:
Ich habe auf der laufenden FHEM Instanz nun mal Apptime laufen lassen.
Einen "Bremsklotz" konnte ich schon identifizieren: Mein SML Stromzähler bzw. der Lesekopf
Auszug aus Apptime:
name function max count total average maxDly avgDly TS Max call param Max call
JeelinkGateway LaCrosseGateway_Read 2101 4218 36305.00 8.61 0.00 0.00 29.10. 18:16:52 HASH(JeelinkGateway)
FileLog_Temp_Esszimmer FileLog_Log 2090 7115 8436.51 1.19 0.00 0.00 29.10. 18:16:52 HASH(FileLog_Temp_Esszimmer); HASH(Temp_Esszimmer)
stromzaehlerkopf OBIS_Read 1464 510434 162939.34 0.32 0.00 0.00 29.10. 18:17:25 HASH(stromzaehlerkopf)
powerlog FileLog_Get 1438 53 71703.35 1352.89 0.00 0.00 29.10. 18:01:52 HASH(powerlog); powerlog; -; -; 2021-10-29_00:00:00; 2021-10-30_00:00:00; 4:stromzaehlerkopf.power\x3a::
powerlog FileLog_Log 1434 1899 31470.72 16.57 0.00 0.00 29.10. 18:17:25 HASH(powerlog); HASH(stromzaehlerkopf)
FileLog_KE_Kuehlschrank FileLog_Log 1410 29 2810.22 96.90 0.00 0.00 29.10. 17:59:40 HASH(FileLog_KE_Kuehlschrank); HASH(KE_Kuehlschrank)
WEB_94.219.252.192_52326 FW_Read 1245 20 1929.07 96.45 0.00 0.00 29.10. 18:02:53 HASH(WEB_94.219.252.192_52326)
FileLog_Temp_Keller FileLog_Log 930 213 3096.72 14.54 0.00 0.00 29.10. 18:44:26 HASH(FileLog_Temp_Keller); HASH(Temp_Keller)
MQTT2Server_192.168.2.25_60360 MQTT2_SERVER_Read 707 768 13780.83 17.94 0.00 0.00 29.10. 18:08:06 HASH(MQTT2Server_192.168.2.25_60360)
FileLog_POWSolar FileLog_Log 684 70 2576.24 36.80 0.00 0.00 29.10. 18:08:06 HASH(FileLog_POWSolar); HASH(POWSolar)
FileLog_Temp_Wohnzimmer FileLog_Log 540 52 919.88 17.69 0.00 0.00 29.10. 18:22:56 HASH(FileLog_Temp_Wohnzimmer); HASH(Temp_Wohnzimmer)
Temp_Esszimmer habe ich schon angepasst. Den musste ich wegen Batteriewechsel neu anlegen, daher waren die Event-Min und on-change noch nicht gesetzt.
Folgendes Verhalten:
der Wert "Power" beim SML Kopf wird recht oft geschrieben, so ca. alle 1-3 Sekunden. Das möchte ich auch beibehalten als Reading im Device damit ich quasi instant Verbraucher erkennen kann und auch deren Stromverbrauch bzw. Watt-Leistung.
Allerdings wollte ich eigentlich nur alle 30-60 Sekunden ins Logfile schreiben, das reicht mir für SVGs mehr als dicke aus.
Ich hatte bereits Event-on-change-reading und event-min-interval gesetzt und damit getestet. Allerdings wird dann das reading natürlich auch nicht mehr so oft geschrieben. Wie gesagt, das möchte ich aber beibehalten.
Ich habe gesucht, allerdings dazu im Forum nichts gefunden.
In der Specific Help von "FILELOG" allerdings einen Punkt gefunden, der für diesen Einsatzzweck von Interesse sein kann.
Also events beibehalten, LOG aber reduzieren.
Und zwar als Attribut im FILELOG filelog-event-min-interval
Allerdings bin ich mir mit der Syntax noch nicht sicher.
Das teste ich aber jetzt aus und gebe dann noch mal ein Update, falls das noch mal jemand so sucht.
***Update***
Folgende Syntax hat geholfen und nur noch alle 30 Sekunden wird nun der Wert ins Logfile geschrieben:
attr powerlog filelog-event-min-interval stromzaehlerkopf:(power).*:30
Grüße
Panger
Ich habs auf einem Pi 4 laufen und die gleichen Schwierigkeiten, dass FTUI recht träge ist und das komplette Laden einer Seite bis zu 10 Sekunden dauern kann.
Deshalb habe ich fast alles mit Popups gelöst, um fast nie eine andere Seite laden zu müssen.
Hier im Forum ist ja schon vom Nachfolger FTUI version 3 zu lesen, was in jeder Hinsicht flotter sein soll.
Leider ist kaum etwas für Laien dokumentiert, weshalb ich den Umstieg bisher vor mir herschiebe.
Zitat von: Dracolein am 29 Oktober 2021, 20:53:07Hier im Forum ist ja schon vom Nachfolger FTUI version 3 zu lesen, was in jeder Hinsicht flotter sein soll.
Leider ist kaum etwas für Laien dokumentiert, weshalb ich den Umstieg bisher vor mir herschiebe.
Das liegt uA daran, dass FTUI3 noch wip bzw beta-status und somit noch nicht richtig fertig ist. Es ist aber Brauchbar und anhand der Beispiele auch gut abzuleiten imho. Und ja, gegenüber FTUI2 ist FTUI3
wesentlich schneller.
Meine FTUI2 Seite benötigte bis zu 6s bis es dargestellt worden ist - der gleiche Aufbau mit FTUI3 dauert ganze 190ms (was für FTUI3 Verhältnisse langsam ist, liegt aber an meinem Kosntrukt).
Im Übrigen hängt die Geschwindigkeit vom FTUI primär von der Potenz (aka Rechenleistung) des Anzeigegeräts und der Verbindung zum FHEM-Server ab. Die meisten Funktionen werden auf Clientseite (sprich: Browser) berechnet. FTUI3 ist JavaScript-seitig aber wesentlich schlanker und einfacher, von daher auch schneller.