Hauptmenü

Neueste Beiträge

#11
MQTT / Aw: mqtt2 logfile mit RegEx be...
Letzter Beitrag von brembs - 09 Februar 2026, 21:30:59
Habe die Klammern gesetzt, aber wie es aussieht, werden immer noch alle Werte, alle 5s ins LogFile geschrieben:

define FileLog_OpenDTU FileLog ./log/OpenDTU-%Y-%m.log (OpenDTU|OpenDTU:1164a00f98e9_0_power:.*|OpenDTU:1164a00f98e9_0_powerdc:.*|OpenDTU:1164a00f98e9_0_temperature:.*|OpenDTU:1164a00f98e9_1_power:.*|OpenDTU:1164a00f98e9_2_power:.*|OpenDTU:1164a00f98e9_3_power:.*|OpenDTU:1164a00f98e9_4_power:.*|OpenDTU:power:.*)
LogFile:
2026-02-09_21:25:54 OpenDTU uptime: 114731
2026-02-09_21:25:54 OpenDTU ip: 192.168.178.60
2026-02-09_21:25:54 OpenDTU hostname: OpenDTU
2026-02-09_21:25:54 OpenDTU size: 315676
2026-02-09_21:25:54 OpenDTU free: 187192
2026-02-09_21:25:54 OpenDTU minfree: 148448
2026-02-09_21:25:54 OpenDTU maxalloc: 172020
2026-02-09_21:25:54 OpenDTU rssi: -62
2026-02-09_21:25:54 OpenDTU bssid: E0:28:6D:68:F7:3A
2026-02-09_21:25:54 OpenDTU name: Kamin
2026-02-09_21:25:54 OpenDTU tx_request: 31936
2026-02-09_21:25:54 OpenDTU tx_re_request: 6
2026-02-09_21:25:54 OpenDTU rx_success: 7547
2026-02-09_21:25:54 OpenDTU rx_fail_nothing: 24346
2026-02-09_21:25:54 OpenDTU rx_fail_partial: 1
2026-02-09_21:25:54 OpenDTU rx_fail_corrupt: 42
2026-02-09_21:25:54 OpenDTU rssi: -37
2026-02-09_21:25:54 OpenDTU bootloaderversion: 101
2026-02-09_21:25:54 OpenDTU fwbuildversion: 10027
2026-02-09_21:25:54 OpenDTU fwbuilddatetime: 2023-06-05 10:24:00
2026-02-09_21:25:54 OpenDTU hwpartnumber: 270692642
2026-02-09_21:25:54 OpenDTU hwversion: 01.10
2026-02-09_21:25:54 OpenDTU limit_relative: 100.00
2026-02-09_21:25:54 OpenDTU limit_absolute: 2000.00
2026-02-09_21:25:54 OpenDTU reachable: 0
2026-02-09_21:25:54 OpenDTU producing: 0
2026-02-09_21:25:54 OpenDTU last_update: 1770654511
2026-02-09_21:25:55 OpenDTU yieldtotal: 19.045
2026-02-09_21:25:55 OpenDTU yieldday: 0
2026-02-09_21:25:55 OpenDTU is_valid: 0
2026-02-09_21:25:55 OpenDTU irradiation: 0.000
2026-02-09_21:25:55 OpenDTU is_valid: 0
2026-02-09_21:25:59 OpenDTU uptime: 114736
2026-02-09_21:25:59 OpenDTU ip: 192.168.178.60
2026-02-09_21:25:59 OpenDTU hostname: OpenDTU
2026-02-09_21:25:59 OpenDTU size: 315676
2026-02-09_21:25:59 OpenDTU free: 187192
2026-02-09_21:25:59 OpenDTU minfree: 148448
2026-02-09_21:25:59 OpenDTU maxalloc: 172020
2026-02-09_21:25:59 OpenDTU rssi: -62
2026-02-09_21:25:59 OpenDTU bssid: E0:28:6D:68:F7:3A
2026-02-09_21:25:59 OpenDTU name: Kamin
2026-02-09_21:25:59 OpenDTU tx_request: 31939
2026-02-09_21:25:59 OpenDTU tx_re_request: 6
2026-02-09_21:25:59 OpenDTU rx_success: 7547
2026-02-09_21:25:59 OpenDTU rx_fail_nothing: 24349
2026-02-09_21:25:59 OpenDTU rx_fail_partial: 1
2026-02-09_21:25:59 OpenDTU rx_fail_corrupt: 42
2026-02-09_21:25:59 OpenDTU rssi: -37
2026-02-09_21:25:59 OpenDTU bootloaderversion: 101
2026-02-09_21:25:59 OpenDTU fwbuildversion: 10027
2026-02-09_21:25:59 OpenDTU fwbuilddatetime: 2023-06-05 10:24:00
2026-02-09_21:25:59 OpenDTU hwpartnumber: 270692642
2026-02-09_21:25:59 OpenDTU hwversion: 01.10
2026-02-09_21:25:59 OpenDTU limit_relative: 100.00
2026-02-09_21:25:59 OpenDTU limit_absolute: 2000.00
2026-02-09_21:25:59 OpenDTU reachable: 0
2026-02-09_21:25:59 OpenDTU producing: 0
2026-02-09_21:25:59 OpenDTU last_update: 1770654511
2026-02-09_21:26:00 OpenDTU yieldtotal: 19.045
2026-02-09_21:26:00 OpenDTU yieldday: 0
2026-02-09_21:26:00 OpenDTU is_valid: 0
2026-02-09_21:26:00 OpenDTU irradiation: 0.000
2026-02-09_21:26:00 OpenDTU is_valid: 0

Scheint doch etwas anderes zu sein. Für mich sieht die Syantx eigentlich genau so aus, wie bei meinen anderen Devices, wo es funktioniert. Irgendetwas übersehe ich...
#12
Off-Topic / Aw: Hostname auf Pi plötzlich ...
Letzter Beitrag von passibe - 09 Februar 2026, 21:26:35
Das hier hat nichts mit Docker zu tun.

Die Hostnamen von Docker sind immer nur über den Docker DNS-Resolver verfügbar und dieser ist nur innerhalb der Container verfügbar! (Der Resolver läuft innerhalb der Container über 127.0.0.11, ist für dieses Problem jetzt aber völlig ohne Belang).

Auf dem Host selbst sind die Hostnamen der Container nicht auflösbar, genausowenig durch andere Geräte im Netzwerk.

Das hier ist aber ohnehin kein Hostname des Containers, also vergiss (für die Beantwortung dieser Frage) einfach alles, was ich über Docker gesagt habe.

Hier hast du einfach lokal auf deinem System deinem Pi den Hostnamen "fhempi" zugewiesen, deshalb auch der Eintrag in der /etc/hosts-Datei (siehe hier).

Deshalb klappt vom Pi aus dieser Befehl auch immer
Zitat von: TomLee am 09 Februar 2026, 18:08:46curl --head --insecure https://fhempi
weil der Pi selbst (zuerst) in seiner /etc/hosts-Datei nachschaut und herausfindet, dass der Hostname fhempi zu 127.0.1.1 (Loopback-Interface) führt und dieses dann anfragt.

Andere Geräte haben diesen Eintrag in ihrer /etc/hosts-Datei (sofern es eine gibt) aber nicht,* fragen deshalb den per DHCP oder sonst konfigurierten DNS-Resolver an (meist deinen Router, der wiederum normalerweise den DNS-Resolver deines ISP anfragt) und weil fhempi keine ordentlich irgendwo registrierte Domain ist, gibts dazu auch keinen DNS-Eintrag, der auf irgendeine IP verweisen kann. Deshalb klappt dann die Abfrage per Hostnamen auch nicht.

Das gilt übrigens auch für Docker-Container, auch die haben eine eigene /etc/hosts und sehen nicht die /etc/hosts des Docker-Hosts. Abgesehen davon würde ein striktes 1:1-Mapping der Docker-Host-/etc/hosts in die Docker-Container-/etc/hosts auch nichts bringen, weil die Container (sofern nicht network_mode host genutzt wird) jeweils eigene Netzwerkinterfaces haben, sodass das unter * Gesagte gilt.

*Wichtig ist, dass der Eintrag 127.0.1.1 sowieso komplett nutzlos für die anderen Geräte wäre, weil das ja nicht die LAN-IP deines Pi ist; der Request von cURL geht also gar nicht ins LAN, sondern bleibt auf dem Loopback-Interface. Der Hostname fhempi darf sich also, damit er nützlich für andere Computer im Netzwerk ist, nicht zu 127.0.1.1 auflösen. Dann würden die nämlich nur einen Request zu ihrem eigenen Loopback-Interface machen und nicht über das LAN zu deinem Pi.

Soweit jedenfalls die Theorie.

Was jetzt aber häufig passiert, ist, dass sich Geräte per DHCP unter ihrem Hostnamen anmelden und der DHCP-Server, der auf dem Router läuft, im DNS-Resolver, der ebenfalls auf dem Router läuft, einen Eintrag zu der jeweiligen IP-Adresse hinterlegt und zwar mit dem Hostnamen, mit dem sich die Geräte per DHCP angemeldet haben.

Dann spart man sich das manuelle Konfigurieren der DNS-Einträge fürs Heimnetzwerk und kann die Geräte, so wie du es willst, einfach mit ihrem Hostnamen aufrufen. Macht allen voran die Fritzbox so, teilweise auch mit $HOSTNAME.fritz.box. (Bin mir grade nicht sicher, ob das fritz.box zwingend erforderlich ist, oder nur $HOSTNAME reicht.)

Mit ziemlciher Sicherheit wird das auch bei dir so sein, dass dein Pi beim DHCP-Request nach dem Booten seinen Hostnamen mitschickt und dann ein DNS-Eintrag gesetzt wird. Vermutlich ist es jetzt so, dass dein Router so eingestellt ist, dass die DHCP-Lease nach 24 Stunden abläuft und damit eben auch der DNS-Eintrag. Und dann schlägt die Namensauflösung fehl.

Aus irgendeinem Grund sendet dein Pi also nicht wiederholt DHCP-Renew Anfragen an den DHCP-Server, sodass die Lease abläuft.

Deshalb:
  • Hast du für den Pi im Pi selbst eine statische IP konfiguriert?
  • Oder bekommt er eine statische IP vom DHCP-Server?
  • Läuft auf dem Pi der DHCP-Client? (Unter Raspbian dhclient, glaube ich, aber nicht sicher.)
  • Steht irgendwas DHCP-bezogenes im Syslog vom Pi unmittelbar nach dem Booten?
  • Steht irgendwas DHCP-bezogenes im Syslog vom Pi nach 24 Stunden uptime?
  • Was gibt sudo ss -tulpn zurück? (siehe unten)

Sorry, ist jetzt vielleicht ein bisschen durcheinander alles, feel free, das in irgendein LLM deiner Wahl zu werfen, damit es besser strukturiert und verständlicher wird.

Übrigens: Es gibt auch noch sowas wie mDNS, das könnte hier theoretisch auch noch eine Rolle spielen, aber wage ich prinzipiell mal zu bezweifeln. Wobei es durchaus sein könnte, je nach dem, was das für eine Anwendung ist, die da läuft. Typischerweise funktioniert mDNS aber mit *.local-Adressen, die benutzt du hier ja nicht. Gib uns der Vollständigkeit halber vielleicht trotzdem mal die Ausgabe von sudo ss -tulpn, dann sehen wir, ob da irgendwas mDNS-mäßiges läuft (UDP-Port 5353) (und, wie mir grade auffällt auch, ob der DHCP-Client läuft (UDP-Port 68)).
#13
Anfängerfragen / Aw: Integration Valetudo Staub...
Letzter Beitrag von Otto123 - 09 Februar 2026, 21:14:57
mqtt2 Device anlegen lassen und das Template valetudo anwenden - funktioniert eigentlich. Zumindest start stop usw geht noch.
Aber einiges funktioniert derzeit nicht, ich weiß nicht warum. Muss ich mal schauen ...

Da gab es hier den Entstehungsthread https://forum.fhem.de/index.php?topic=121017.0 musst Du aber nicht durcharbeiten.

Mit der Karte wird das damit allerdings nichts. Ich weiß nicht ob es da mittlerweile eine sinnvolle Lösung gibt, ich habe das seinerzeit nicht verstanden und aufgegeben.

Gruß Otto
#14
MQTT / Aw: mqtt2 logfile mit RegEx be...
Letzter Beitrag von brembs - 09 Februar 2026, 21:05:00
Ah, ok, sehr interessant! Habe die Syntax vom Frontend erstellen lassen (also mit den Buttons in der Detailansicht) und nicht selbst geschrieben, so dass ich davon ausging, dass es funktionieren sollte. Werde ich sofort testen und zurückmelden, danke!
#15
SVG / Plots / logProxy / Aw: Bitte um Review: Erweiteru...
Letzter Beitrag von WW - 09 Februar 2026, 20:05:39
Hier erst einmal eine modifizierte gplot-Datei, mit der ich die folgenden Screenshots erstellt habe:

# Created by FHEM/98_SVG.pm, 2017-02-28 11:30:56
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<L1>'
##set ytics
set xtics
set ytics ("0" 0, "300" 300, "600" 600, "900" 900, "1200" 1200, "1500" 1500, "1800" 1800, "2100" 2100, "2400" 2400)
set y2tics ("3" 3, "3.5" 3.5, "4" 4, "4.5" 4.5, "5" 5, "5.5" 5.5, "6" 6, "6.5" 6.5, "7" 7)
set y3tics ("-5" -5, "-2.5" -2.5, "0" 0, "2.5" 2.5, "5" 5, "7.5" 7.5, "10" 10, "12.5" 12.5, "15" 15)
set grid y2tics
set ylabel "Energie / [kWh]"
set y2label "COP"
set y3label "Temperatur / [°C]"
set yrange [0:2400]
set y2range [3:7]
set y3range [-5:15]

#logProxy DbLog:DBLogging,offset=-24*3600*15:doifDatenVerdichten:KgWsWpCop_last_month
#logProxy Func:my_Flexible_Avg_Dots(2,$from,$to,"DbLog:DBLogging:Lambda:statGeneralAmbient-ActualAmbientTempDayAvgLast","month",0.5)
##logProxy Func:my_Interval_Bar_Fix(3,$from,$to,"DbLog:DBLogging:myCounter:WpStromaufnahme_last_month",0.8)
##logProxy Func:my_Interval_Bar_Fix(4,$from,$to,"DbLog:DBLogging:myCounter:WpWaerme_last_month",0.8)


##plot "<IN>" using 1:2 axes x1y2 title 'Gesamt-COP (Monat)' ls l5 lw 3 with points:minus:10,\
##    "<IN>" using 1:2 axes x1y3 title 'Ø-Temperatur (Monat)' ls l1 lw 2 with points:circle:3,\
##    "<IN>" using 1:2 axes x1y1 title 'Energieaufnahme Monat (elektrisch)' ls l3fill lw 1 with lines,\
##    "<IN>" using 1:2 axes x1y1 title 'Wärmeabgabe Monat (thermisch)' ls l0fill lw 1 with lines

plot "<IN>" using 1:2 axes x1y2 title 'Gesamt-COP (Monat)' ls l5 lw 3 with points:square:10,\
    "<IN>" using 1:2 axes x1y3 title 'Ø-Temperatur (Monat)' ls l5fill lw 3 with points:circle:10,\


Mit der derzeit aktuellen 98_SVG.pm aus dem Repo ergibt sich ein Bild analog den Screenshots "screenshot_l1.png" bis "screenshot_l8". Geändert ist hier jeweils die Ziffer hinter dem "l".

Die Quadrate sind jeweils ohne Füllung, die Kreise mit. Es sieht so aus, als ob für l1 bis l3 beide Umrandungs-Farben gleich sind, für l4 bis l8 haben die gefüllten Kreise falsche Farbzuordnungen.

Betrachtet man im Dropdownmenue des Ploteditors die Farben für die einzelnen "l"-Varianten (z.B. l1, l1_fill, l1_dot, ...) so vermute ich, dass die Umrandungsfarbe für die gleiche Ziffer (hinter dem l) stets gleich sein sollte.

Sollte der Fehler "lediglich" in den css-Definitionen liegen, so ist mein letzter Patchvorschlag hinfällig, da dann da alles richtig ist.

Edit 1: Noch ein Hinweis: Ich verwende den "f18"-Style

Edit 2:
Auszug aus svg_style.css:
.SVGplot.l0     { stroke:red;     }
.SVGplot.l1     { stroke:green;   }
.SVGplot.l2     { stroke:blue;    }
.SVGplot.l3     { stroke:magenta; }
.SVGplot.l4     { stroke:brown;   }
.SVGplot.l5     { stroke:black;   }
.SVGplot.l6     { stroke:olive;   }
.SVGplot.l7     { stroke:gray;    }
.SVGplot.l8     { stroke:yellow;  }

.SVGplot.l0fill { stroke:red;         fill:url(#gr_0); }
.SVGplot.l1fill { stroke:forestgreen; fill:url(#gr_1); }
.SVGplot.l2fill { stroke:blue;        fill:url(#gr_2); }
.SVGplot.l3fill { stroke:magenta;     fill:url(#gr_3); }
.SVGplot.l4fill { stroke:yellow;      fill:url(#gr_4); }
.SVGplot.l5fill { stroke:cyan;        fill:url(#gr_5); }
.SVGplot.l6fill { stroke:black;       fill:url(#gr_6); }
.SVGplot.l7fill { stroke:brown;       fill:url(#gr_7); }
.SVGplot.l8fill { stroke:olive;       fill:url(#gr_8); }

.SVGplot.l0dot  { stroke:red;     stroke-dasharray:2,4; }
.SVGplot.l1dot  { stroke:green;   stroke-dasharray:2,4; }
.SVGplot.l2dot  { stroke:blue;    stroke-dasharray:2,4; }
.SVGplot.l3dot  { stroke:magenta; stroke-dasharray:2,4; }
.SVGplot.l4dot  { stroke:brown;   stroke-dasharray:2,4; }
.SVGplot.l5dot  { stroke:black;   stroke-dasharray:2,4; }
.SVGplot.l6dot  { stroke:olive;   stroke-dasharray:2,4; }
.SVGplot.l7dot  { stroke:gray;    stroke-dasharray:2,4; }
.SVGplot.l8dot  { stroke:yellow;  stroke-dasharray:2,4; }

.SVGplot.l0fill_stripe { stroke:red;     fill:url(#gr0_stripe);}
.SVGplot.l1fill_stripe { stroke:green;   fill:url(#gr1_stripe);}
.SVGplot.l2fill_stripe { stroke:blue;    fill:url(#gr2_stripe);}
.SVGplot.l3fill_stripe { stroke:magenta; fill:url(#gr3_stripe);}
.SVGplot.l4fill_stripe { stroke:brown;   fill:url(#gr4_stripe);}
.SVGplot.l5fill_stripe { stroke:black;   fill:url(#gr5_stripe);}
.SVGplot.l6fill_stripe { stroke:olive;   fill:url(#gr6_stripe);}
.SVGplot.l7fill_stripe { stroke:gray;    fill:url(#gr7_stripe);}
.SVGplot.l8fill_stripe { stroke:yellow;  fill:url(#gr8_stripe);}

Macht es irgendeinen Sinn, das die Farbzuordnungen für ".SVGplot.l?fill" (und auch "text.SVGplot.l?fill") nicht dem Muster der anderen Zuordnungen entsprechen? Mit den hier (falschen) Zuordnungen lässt sich das gesamte Verhalten erklären.
#16
Off-Topic / Aw: Hostname auf Pi plötzlich ...
Letzter Beitrag von TomLee - 09 Februar 2026, 19:52:55
ZitatAlso z.B. wie ist der container fhempi mit dem Host verbunden?

Ich habe mit Docker ehrlich gesagt noch zu wenig Erfahrung, um die geforderten Details zur Container-Anbindung auf Anhieb liefern zu können, beschäftige mich damit aber und reiche die Infos ggf. nach.

Inzwischen habe ich festgestellt, dass das Problem identisch auch bei FHEM oder anderen Anwendungen  auftritt, also unabhängig von Docker. Der Zugriff über die IP-Adresse funktioniert immer, betroffen ist ausschließlich der Hostname.

Daher gehe ich aktuell davon aus, dass es nicht direkt mit Docker zusammenhängt.
#17
Sonstiges / Aw: httpmod.template: bugs, Fr...
Letzter Beitrag von DeeSPe - 09 Februar 2026, 19:23:21
Zitat von: Tueftler1983 am 09 Februar 2026, 18:17:06Hey also nach kurzer anpassung des Regexp hat es soforg funktioniert, lasse jetzt mal beide Paralel laufen und schaue es mir weiter an!

Besten Dank für's Testen.
Habe eben noch Kleinigkeiten in #275 aufgeräumt: Attribut angepasst (nur noch "showDevices:all,updatable" statt "showUpdatableDevices:all,onlyUpdatable"), überflüssigen Code aus stateFormat entfernt und unnötige Attribute entfernt.
Das sollte es nun aber endgültig gewesen sein.
Ich bin zumindest recht zufrieden damit jetzt.

Gruß
Dan
#18
Off-Topic / Aw: Hostname auf Pi plötzlich ...
Letzter Beitrag von Sidey - 09 Februar 2026, 19:16:54
Kannst Du mehr Informationen zu deinem Netzwek geben?

Also z.B. wie ist der container fhempi mit dem Host verbunden?

Grüße Sidey
#19
FRITZ!Box / Aw: 72_FRITZBOX.pm ab Version...
Letzter Beitrag von Prof. Dr. Peter Henning - 09 Februar 2026, 19:05:25
98_BOSEST.pm wird derzeit massiv überarbeitet, wäre kein Problem, das zu ändern.

LG

pah
#20
Automatisierung / Aw: [98_monitoring] - Support ...
Letzter Beitrag von Beta-User - 09 Februar 2026, 19:04:59
Zitat von: Gernott am 07 Februar 2026, 17:08:55Nein, ich habe fast nur Homematic-Geräte (~30) und einige wenige MQTT2-Devices, die allerdings nicht viel Event-Last erzeugen. Außerdem fehlen jetzt im Winter etliche HM-Geräte, da der Pool nicht im Betrieb ist. Neuzugänge waren nur die beiden Monitoring-Instanzen.
Hmm, bin im Moment ohne Idee. Meine monitoring-Instanzen sind im Moment so angelegt, dass Sie ein NOTIFYDEF als Internal haben. 
Aber deine Grafiken zeigen v.a. auch kein swappen oä., und die ~200MB RAM sind ja auch stabil. Bei Gelegenheit schaue ich mir den Code mal an, aber wenn es ein generelles Problem wäre, hätte ich (bei mind. 164 Nutzern lt. Statisitk) viel früher mit Problemmeldungen gerechnet...