Hallo zusammen,
ich möchte gern ein paar zeitfressende devices aus der Haupt-Instanz auslagern. So zeigt mir apptime z.B., daß meine HMUarts und der JeeLink ganz oben in der Zeitfresser Liste stehen. Auch das Statistik Modul wird mit wachsender Anzahl an Devices, wo ich Statistik haben möchte, zeitkritischer. Ich habe 5 HMUarts laufen, sie sind alle im Haus und auf dem Grundstück verteilt, um die Funkausleuchtung sicherzustellen. 4 Stück stecken auf Raspis und sind per socat oder ser2net publiziert und per LAN erreichbar, einer hängt an einem D1 Mini und kommt per WLAN, das scheint aber nicht zu bremsen. Das MQTT device verursacht auch ordentlich Verzögerungen. Da hängen aktuell 77 devices dran, wenn ich das auf MQTT2 umbauen wollte, müßte ich wohl Urlaub nehmen. Der mosquitto Broker läuft lokal auf dem fhem-NUC, ich benutze noch die MQTT Generic Bridge.
Mir ist noch nicht ganz klar, ob fhem2fhem der richtige Ansatz ist - und wenn ja - wie man die Architektur generell am besten aufbaut.
Ich habe z.B. noch ein sauberes Dev-Fhem in einer VM laufen zum rumprobieren.
Wenn ich die kritischen IOs jetzt in dem leeren Dev-fhem definiere und die events per fhem2fhem übertrage (wobei mir die Details noch keineswegs klar sind), baue ich mir damit womöglich zusätzliche Verzögerungen ein, oder wird das Gesamtverhalten besser?
Als erste Performance Maßnahme habe ich vor, die Hauptinstanz vom derzeitigen Gen8 Celeron NUC mit 8GB RAM und Ubuntu 16.04 auf einen Gen11 NUC mit i5, M2 NVME SSD, 32GB RAM und Ubuntu 22.04 umzuziehen. Er liegt schon bereit, ist soweit vorbereitet und wartet nur noch auf den günstigen Moment, wo ich genug Zeit für den Umzug und eventuelle Probleme habe.
Nach dem Umzug hätte ich auch den alten NUC frei, um dort ein neues Ubuntu und ein leeres fhem draufzupacken.
Wie würdet Ihr das angehen?
Gruß Roland
Ich würde nicht nur, sondern ich habe verschiedene FHEM-Instanzen. Und übertrage keineswegs alle Events mit fhem2fhem, sondern nur diejenigen, die benötigt werden.
Instanz Nr. 1 (IP ..90)bedient die meisten Draht- und Funkinterfaces: 1-Wire, HomeMatic, HomeMatic IP, FS20, ZigBee, Shelly für Beleuchtung, Heizung, Sicherheit etc.. Also Dinge, bei denen eine Verzögerung auffallen würde.
Instanz Nr. 2 (IP ..94) ist für (fast) alles zuständig, das mit HTML operiert: Bosch-Siemens Hausgeräte, Externe Daten (Gammastrahlung, Rheinpegel), drei Roomba Staubsaugroboter via MQTT, ein Telegram-Interface und meine 3D-Drucker. Und natürlich die Ansteuerung aller Mediengeräte, ferner Sprachausgabe und Spracheingabe. Also Dinge, bei denen eine Verzögerung weniger auffällt.
Instanz Nr. 3 ist ein RaspBerry Pi Zero auf dem Garagendach, der meine Wetterdaten sammelt und an die anderen Instanzen weiterleitet. Das hat sich als sehr sicher gegen Blitzschlag erwiesen.
Instanz Nr. 4 ist mein Finanzserver, der die Börsenkurse abfragt und anzeigt.
Auf meinen Bedientabets (Tablet-UI, mit diversen eigenen Widgets (siehe mein FHEM-Buch)) kann ich die Bedienung der Dinge sogar ganz gut mischen, ohne dass man bemerkt, mit welcher Instanz man es zu tun hat.
Datenübertragung zwischen den Instanzen: Ich habe diverse CustomReadings, die mehrere Daten zusammenfassen - z.B.
ZitatenergyProfile 0.96 8.196 0 0 3.014 12.487 114.2857 5.87 0 169
Auf jeder FHEM-Instanz gibt es FHEM2FHEM-Instanzen für ALLE anderen Instanzen, z.B. auf der Instanz mit der IP-Adresse x.x.x.90:
define Task_94 FHEM2FHEM x.x.x.94:7073 LOG:noneBedient werden diese über Perl-Kommandos
sub fhem94Cmd($){
my ($cmd) = @_;
fhem("set Task_94 cmd ".$cmd);
}Sobald sich nun an einem der "Sammelprofile" etwas ändert, reagiert ein DOIF und überträgt die Daten auf die andere Instanz, mit
({fhem94Cmd("{evalProfile('energy','".Value("energyProfile")."')}")})evalProfile ist eine Perl-Routine auf der entfernten Instanz, welche die Daten wieder auseinander nimmt und auf einzelne Readings verteilt.
Warum mache ich das? Weil dabei der Overhead für die FHEM2FHEM-Nachrichten sehr gerin gist.
Für die Sprachausgabe gibt es auf jeder Instanz eine Perl-Routine. Auf allen Instanzen, die selbst keine Sprachausgabe machen, wird dies nur an 94 Instanz weitergeleitet:
sub speak($$){
my ($name,$text) = @_;
fhem("set Task_94 cmd {speak('$name','$text')}");
}Auf der 94er-Instanz wird das dann ausgewertet: Entweder der Text direkt an ein Android Device weitergeleitet. Auf den Tablets (oder alten Handys, die ich als Display verwende) läuft eine ziemlich alte und nicht mehr weit verbreitete Text-to-Speech Instanz, die mit der heutigen Stimme "Marlene" von Amazon Polly arbeitet. Oder aber, für die Ausgabe auf einem beliebigen Linux-System oder einem BOSE-System, wird zunächst der Text mit Hilfe von Amazon Polly in ein MP3 umgewandelt und dann abgespielt.
LG
pah
Vielen Dank für die ausführlichen Erläuterungen.
Mein fhem ist über viele Jahre gewachsen, wie wahrscheinlich bei den Meisten hier. Mit dem Wissen von heute hätte ich Einiges anders gemacht. Begonnen hat es ganz harmlos mit drei Fensterkontakten und drei Heizthermostaten, nicht ahnend, wie das wachsen kann.
Mittlerweile habe ich einige unangenehme Verzögerungen, die insbesondere beim Schalten von Licht und der Verarbeitung von Bewegungsmelder-Events unangenehm auffallen. Freezemon und apptime liefern genug Anhaltspunkte für Handlungsbedarf. Bisher konnte ich Engpässe immer mit kräftigerer Hardware erschlagen. Damit schiebt man natürlich die Problematik nur ein Stück hinter den aktuellen Horizont.
Da ich demnächst meinen alten NUC frei habe, werde ich das Ganze mal anfangen zu entflechten. Aufräumen ist eigentlich ein Job für die kürzeren Tage, aber irgendwann muß man anfangen. Mein neuer ESXi-NUC wartet auch auf neue Aufgaben, da werde ich auch eine fhem Instanz drauf legen. Es ist doch immer wieder schön, mit dem Computer Probleme zu lösen, die man ohne ihn gar nicht hätte.
Gruß Roland
Ich habe gestern mein fhem erfolgreich auf den neuen NUC umgezogen und damit erstmal wieder erheblich mehr Schwuppdizität. Die WebGUI reagiert sehr viel schneller, wahrscheinlich auch, weil ich mit einer leeren DbLog anfange und diesmal von Anfang an zyklisch verdichte.
Trotzdem möchte ich die langsamen devices auslagern. Ich möchte mit dem JeeLink anfangen. Ich habe dazu einen alten Beitrag von 2014 (https://forum.fhem.de/index.php?topic=25399.0) gefunden, der mit einer named pipe arbeitet.
Ich habe das zum Testen erstmal "anders herum" konfiguriert, heißt, ich lasse den JeeLink zum Test erstmal in meiner Hauptinstanz und lege den Remote JeeLink in meiner fhem-dev Instanz an, um zu schauen, ob da was ankommt. Die named pipe "jdummy" habe ich als root angelegt, aber die Rechte auf fhem:dialout geändert.
Auf Remote Seite (fhem-dev):
Das JeeLink device:
Internals:
CFGFN
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /opt/fhem/tmp/jdummy@directio
DeviceName /opt/fhem/tmp/jdummy@directio
FUUID 64d8e708-f33f-a5bb-71b6-901808148ce1c0b4
NAME myJeeLink
NR 155
PARTIAL
STATE disconnected
TYPE JeeLink
eventCount 2
MatchList:
1:PCA301 ^\S+\s+24
2:EC3000 ^\S+\s+22
3:RoomNode ^\S+\s+11
4:LaCrosse ^(\S+\s+9 |OK\sWS\s)
5:AliRF ^\S+\s+5
6:EMT7110 ^OK\sEMT7110\s
7:KeyValueProtocol ^OK\sVALUES\s
READINGS:
2023-08-13 16:37:54 state disconnected
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
Das fhem2fhem device:
Internals:
CFGFN
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF 192.168.1.53:7072 RAW:myJeeLink
FD 10
FUUID 64d8e74b-f33f-a5bb-5661-be1265a584d42451
Host 192.168.1.53:7072
NAME f2f_53_jeelink
NR 157
PARTIAL
STATE connected
TYPE FHEM2FHEM
informType RAW
rawDevice myJeeLink
Attributes:
Auf Seite der Hauptinstanz:
Das JeeLink device:
Internals:
CFGFN
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF 192.168.1.84:3010
DeviceName 192.168.1.84:3010
FD 22
FUUID 64d8b741-f33f-af18-8a5b-1b48adf806104894
NAME myJeeLink
NR 1480
PARTIAL
RAWMSG OK 9 42 1 4 228 56
STATE initialized
TYPE JeeLink
eventCount 3
initMessages
model LaCrosseITPlusReader.10.1s
myJeeLink_MSGCNT 18560
myJeeLink_TIME 2023-08-13 17:08:00
settings (RFM69CW f:868300 r:17241)
MatchList:
1:PCA301 ^\S+\s+24
2:EC3000 ^\S+\s+22
3:RoomNode ^\S+\s+11
4:LaCrosse ^(\S+\s+9 |OK\sWS\s)
5:AliRF ^\S+\s+5
6:EMT7110 ^OK\sEMT7110\s
7:KeyValueProtocol ^OK\sVALUES\s
READINGS:
2023-08-13 17:08:00 state initialized
hmccu:
Attributes:
alias myJeeLink
devStateIcon initialized:cul_868@green disconnected:cul_868@red
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
group CULs,IOs
icon cul_868
initCommands 0a
room Technikraum
timeout 120,30
Der JeeLink CUL selbst steckt an einem Raspi, der an einem funktechnisch günstigen Standort steht und wird von dort per socat (oder ser2net...) publiziert.
Kann es sein, daß der virtuelle remote JeeLink keinen Connect bekommt, weil der Jeelink-CUL nicht physikalisch an dem NUC mit der Hauptinstanz hängt, sondern auch dort remote via LAN angesprochen wird?
Das sind meine ersten Schritte in fhem2fhem, deshalb bin ich noch etwas unsicher. In dem o.g. Beitrag von 2014 ist nicht die Rede, daß man auf der "anderen Seite" - also meine Hauptinstanz auch noch ein fhem2fhem device braucht. Ich habe trotzdem eins angelegt:
Internals:
CFGFN
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF 192.168.1.214:7072 RAW:myJeeLink
FUUID 64d8e7d7-f33f-af18-e68d-1fe6218ea4373a1e
Host 192.168.1.214:7072
NAME f2f_214_jeelink
NEXT_OPEN 1691941180.89622
NR 1776
PARTIAL
STATE disconnected
TYPE FHEM2FHEM
eventCount 1
informType RAW
rawDevice myJeeLink
hmccu:
Attributes:
alias f2f_214_jeelink
Mit genau dieser Konstellation habe ich ein OBIS device, das allerdings physikalisch am NUC der fhem-Hauptinstanz hängt, in die fhem-dev Instanz übertragen bekommen.
Vielleicht hat jemand Zeit und Muße, sich das mal anzuschauen und hat einen Tip für mich.
Vielen Dank und Gruß
Roland
Heute kam die Erleuchtung.
Es waren wieder mal nur zwei Kleinigkeiten.
1. Die named Pipe war im Verzeichnis /opt/fhem/temp angelegt und die Definition in fhem ging auf /opt/fhem/tmp
2. Ich hatte zwar der named Pipe die Rechte fhem:dialout verliehen, habe aber das selbst angelegte /temp Verzeichnis vergessen, das gehörte noch root
Nach der Korrektur geht nun auch der virtuelle JeeLink im Remote System auf "opened".
Gruß Roland
Moin zusammen, ich habe bezüglich der logs in apptime einmal eine Frage :
tmr-HUEBridge_GetUpdate HASH(0x50992f0) 126 9 1082.37 120.26 874.32 98.96 15.08. 10:15:17 HASH(HUEBridge)
IT_V3_2e951641 IT_Set 54 8 242.50 30.31 0.00 0.00 15.08. 10:10:59 HASH(IT_V3_2e951641); IT_V3_2e951641; on
Was mich stört sind die Frequenz der Abfragen an die HUE Bridge.
Eigentlich brauche ich die genauso wenig als poll wie die IT_Sets (Befehle von anderen Funksendern) die ignoriert werden.
Gibt es da eine Idee, wie ich hier die runtime entlasten kann?