- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#91
TabletUI / Aw: FTUI version 3
Letzter Beitrag von cotecmania - 24 November 2025, 13:07:42Ich benötige in einem ftui-chart-data Textausgaben mit "label", möchte die Daten selbst aber nicht grafisch anzeigen.
Wenn ich "hidden" verwende ist der Text aber durchgestrichen.
Wie kann ich also z.B. $last oder $min als Text oben in der Legende anzeigen, die Messwerte selbst aber nicht als Linie etc. anzeigen ...
Ich möchte kein separates eigenständiges "Label" verwenden, da beim tageweise Blättern im Chart z.B. die Textausgaben entsprechend angepasst werden sollen
Wenn ich "hidden" verwende ist der Text aber durchgestrichen.
Wie kann ich also z.B. $last oder $min als Text oben in der Legende anzeigen, die Messwerte selbst aber nicht als Linie etc. anzeigen ...
Ich möchte kein separates eigenständiges "Label" verwenden, da beim tageweise Blättern im Chart z.B. die Textausgaben entsprechend angepasst werden sollen
#92
Anfängerfragen / aWATTar - Dynamischer Stromtar...
Letzter Beitrag von MiWe58 - 24 November 2025, 12:59:21Hallo,
seit einigen Wochen beschäftige ich mich mit der Option, einen dynamischen Stromtarif abzuschließen. So bin ich auf das "Modul" oder die Anleitung aufmerksam geworden, die Börsentarife über "aWATTar" in Fhem einzulesen. Das funktioniert soweit gut, wie es im Wiki beschrieben ist.
Die folgenden Anlagen sollen möglichst optimal für die Verbrauchsoptimierung und Steuerung über FHEM genutzt werden:
PV-Anlage mit Speicher
Wärmepumpe
e-Auto / Wallbox
PV-Anlage:
Die Anlage ist so groß ausgelegt, dass ich von ca. Anfang/Mitte Mai bis Mitte Oktober zu 100% autark bin, also in das Netz einspeise und einen Bezug von nahezu Null habe
Wärmepumpe:
Die WP wird schon bereits über Fhem angesteuert, um zu optimalen Zeiten Warmwasser aufzubereten und das Haus zu heizen. Auch bei Sonnenschein zu "überheizen", um den Eigenverbrauch zu optimieren und Laufzeiten zu ertragsschwachen Zeiten zu vermeiden.
eAuto/Wallbox
Hier nutze ich die EVCC Software, um PV-optimiert zu laden. Alle Werte stehen über MQTT auf im Fhem zur Verfügung
Trotz der bisherigen Maßnahmen habe ich in der Zeit von Mitte Oktober bis Mitte Mai noch einen Netzbezug von ca 6000 kWh, überwiegend aus Wärmestrom und e-Laden des PKW
Diese hierzu anfallenden Kosten aus einem fixen Stromtarif möchte ich durch einen dynamischen Tarif weiter reduzieren.
Die Fhem - aWATTar-Abfrage ist da bereits eine gute Ausgangslage.
Aus meiner Sicht würde ich einige "Hilfsparameter" zur besseren Steuerungsmöglichkeit ergänzen.
Leider bin ich in der Perl-Programmierung nicht sehr bewandert. Daher hier mein Vorschlag für eine Ergänzung/Erweiterung der bisher dokumentierten Fhem-Integration:
Bisher werden die 4 günstigsten Tarifstunden eines Tages als Reading bereitgestellt
Ergänzend wäre es aus meiner Sicht von Vorteil für eine Steuerung, wenn auch die folgenden Parameter als Readings bereitgestellt werden könnten:
- Die teuersten Stunden (Als Referenz könnte ein unterer Schwellenwert als Parameter vorgegeben werden. z.B. ein Wert aus einem fixen Tarig (Manuelle Vorgabe)
- Die "moderate" Zeitspanne, die unter dem vorgegebenem Schwellwert, aber über den günstigsten Tarifstunden liegt.
Anhand dieser Parameter wären die gesamten 24 Tarifstunden des Tages in "Preisklassen" eingeteilt, die sich, aus meiner Sicht, bereits gut für eine Gesamtoptimierung des Bezugskosten nutzen lassen könnten.
Auch wäre eine Hinterlegung der Tarifdaten in einem Logfile hilfreich, das die richtigen Timestamps zu den jeweiligen Tarifwerten zuordnet. Also die Daten mit dem Timestamp der jeweis gültigen Stunde und des Tagesdatums hinterlegt.
So wären sowohl die Dokumentation des Tarifverlaufes möflich, als auch eine Visualisierung per SVG. Und es könnten noch die Laufzeiten ausgewählter Verbraucher zugefügt werden. Hierzu habe ich im Fhem bisher keine Lösung mit "Bordmitteln" finden können.
Wie bereits geschrieben, bin ich in Perl-Programmierung nicht bewandert, sonst würde ich die Ansätze selbst bereitstellen.
Vielleicht gibt es Interessenten, die das programmiert bekommen, und so die aWATTar-Implementierung ergänzen können
Schöne Grüße
seit einigen Wochen beschäftige ich mich mit der Option, einen dynamischen Stromtarif abzuschließen. So bin ich auf das "Modul" oder die Anleitung aufmerksam geworden, die Börsentarife über "aWATTar" in Fhem einzulesen. Das funktioniert soweit gut, wie es im Wiki beschrieben ist.
Die folgenden Anlagen sollen möglichst optimal für die Verbrauchsoptimierung und Steuerung über FHEM genutzt werden:
PV-Anlage mit Speicher
Wärmepumpe
e-Auto / Wallbox
PV-Anlage:
Die Anlage ist so groß ausgelegt, dass ich von ca. Anfang/Mitte Mai bis Mitte Oktober zu 100% autark bin, also in das Netz einspeise und einen Bezug von nahezu Null habe
Wärmepumpe:
Die WP wird schon bereits über Fhem angesteuert, um zu optimalen Zeiten Warmwasser aufzubereten und das Haus zu heizen. Auch bei Sonnenschein zu "überheizen", um den Eigenverbrauch zu optimieren und Laufzeiten zu ertragsschwachen Zeiten zu vermeiden.
eAuto/Wallbox
Hier nutze ich die EVCC Software, um PV-optimiert zu laden. Alle Werte stehen über MQTT auf im Fhem zur Verfügung
Trotz der bisherigen Maßnahmen habe ich in der Zeit von Mitte Oktober bis Mitte Mai noch einen Netzbezug von ca 6000 kWh, überwiegend aus Wärmestrom und e-Laden des PKW
Diese hierzu anfallenden Kosten aus einem fixen Stromtarif möchte ich durch einen dynamischen Tarif weiter reduzieren.
Die Fhem - aWATTar-Abfrage ist da bereits eine gute Ausgangslage.
Aus meiner Sicht würde ich einige "Hilfsparameter" zur besseren Steuerungsmöglichkeit ergänzen.
Leider bin ich in der Perl-Programmierung nicht sehr bewandert. Daher hier mein Vorschlag für eine Ergänzung/Erweiterung der bisher dokumentierten Fhem-Integration:
Bisher werden die 4 günstigsten Tarifstunden eines Tages als Reading bereitgestellt
Ergänzend wäre es aus meiner Sicht von Vorteil für eine Steuerung, wenn auch die folgenden Parameter als Readings bereitgestellt werden könnten:
- Die teuersten Stunden (Als Referenz könnte ein unterer Schwellenwert als Parameter vorgegeben werden. z.B. ein Wert aus einem fixen Tarig (Manuelle Vorgabe)
- Die "moderate" Zeitspanne, die unter dem vorgegebenem Schwellwert, aber über den günstigsten Tarifstunden liegt.
Anhand dieser Parameter wären die gesamten 24 Tarifstunden des Tages in "Preisklassen" eingeteilt, die sich, aus meiner Sicht, bereits gut für eine Gesamtoptimierung des Bezugskosten nutzen lassen könnten.
Auch wäre eine Hinterlegung der Tarifdaten in einem Logfile hilfreich, das die richtigen Timestamps zu den jeweiligen Tarifwerten zuordnet. Also die Daten mit dem Timestamp der jeweis gültigen Stunde und des Tagesdatums hinterlegt.
So wären sowohl die Dokumentation des Tarifverlaufes möflich, als auch eine Visualisierung per SVG. Und es könnten noch die Laufzeiten ausgewählter Verbraucher zugefügt werden. Hierzu habe ich im Fhem bisher keine Lösung mit "Bordmitteln" finden können.
Wie bereits geschrieben, bin ich in Perl-Programmierung nicht bewandert, sonst würde ich die Ansätze selbst bereitstellen.
Vielleicht gibt es Interessenten, die das programmiert bekommen, und so die aWATTar-Implementierung ergänzen können
Schöne Grüße
#93
FRITZ!Box / Aw: 72_FRITZBOX.pm ab Version...
Letzter Beitrag von JoWiemann - 24 November 2025, 12:58:26Zitat von: bertl am 24 November 2025, 11:44:59Hallo Jörg,
danke für die schnelle Rückmeldung.
Die Sub habe ich nur für Testzwecke entfernt und dann wieder eingefügt, da ich wissen wollte was/wer die Warnung verursacht
Selbstverständlich hast du recht, dass es sich nur um eine Warnung handelt, aber ich kann die Auswirkung auf mögliche andere Module nicht abschätzen und Warnungen habe ja auch einen Grund.
Danke nochmals, Robert
PS: Bitte probiert mal die angehängte Version. Ich habe etwas am Aufruf geändert.
Hallo Robert,
wir hatten eine ähnliche Fehlermeldung schon mal: https://forum.fhem.de/index.php?msg=1134718. Eine Lösung wurde nicht zurückgemeldet. Eine Suche im Netz gab bisher keinen vernünftigen Treffer.
Falls also jemand eine Idee hat.
Grüße Jörg
#94
Sprachsteuerung / Aw: [37_echodevice] Amazon Ech...
Letzter Beitrag von passibe - 24 November 2025, 12:56:45Ich sehe keinen Grund, diesbezüglich derart besorgt zu sein.
Wie oft aktualisieren Leute denn alexa-cookie2? Ich würde wetten, dass das, außer bei Neuinstallationen, quasi nie passiert. Dass die Neuinstallation ausgerechnet in einen Zeitraum fällt, in dem zufällig gerade ein supply chain attack läuft, d.h. die bösartige Version noch nicht zurückgezogen ist, halte ich jetzt auch mal für eher unwahrscheinlich.
Das ganz abgesehen davon, dass alexa-cookie2 auch kein wirklich lukratives Ziel ist, weil es selbst keine dependency von tausenden anderer Pakete ist.
Und alexa-cookie2 wird sowieso vom Entwickler sehr sehr selten aktualisiert (inzwischen Monate bis Jahre), d.h. der Schadcode aus einer bösartigen dependency würde auch nicht von dem typischen Überraschungseffekt durch auto-dependency-updates profitieren.
Wie oft aktualisieren Leute denn alexa-cookie2? Ich würde wetten, dass das, außer bei Neuinstallationen, quasi nie passiert. Dass die Neuinstallation ausgerechnet in einen Zeitraum fällt, in dem zufällig gerade ein supply chain attack läuft, d.h. die bösartige Version noch nicht zurückgezogen ist, halte ich jetzt auch mal für eher unwahrscheinlich.
Das ganz abgesehen davon, dass alexa-cookie2 auch kein wirklich lukratives Ziel ist, weil es selbst keine dependency von tausenden anderer Pakete ist.
Und alexa-cookie2 wird sowieso vom Entwickler sehr sehr selten aktualisiert (inzwischen Monate bis Jahre), d.h. der Schadcode aus einer bösartigen dependency würde auch nicht von dem typischen Überraschungseffekt durch auto-dependency-updates profitieren.
#95
MQTT / Aw: [GELÖST Bitte im FAQ übern...
Letzter Beitrag von Beta-User - 24 November 2025, 12:52:41Und für sowas darf es auch ein neuer Thread sein...
Außer der Mücke gibt es null Gemeinsamkeiten!
Außer der Mücke gibt es null Gemeinsamkeiten!
#96
MQTT / Aw: [GELÖST Bitte im FAQ übern...
Letzter Beitrag von betateilchen - 24 November 2025, 12:48:20Bitte nächstes Mal code-tags verwenden, danke.
Benutzername und Passwort werden bei einer Verbindung zu einem mosquitto Server nicht im DEF des MQTT2_CLIENT angegeben.
Der username wird als Attribut gesetzt, das Passwort wird mit set <device> password <geheimesPassWort> einmalig eingegeben.
Benutzername und Passwort werden bei einer Verbindung zu einem mosquitto Server nicht im DEF des MQTT2_CLIENT angegeben.
Der username wird als Attribut gesetzt, das Passwort wird mit set <device> password <geheimesPassWort> einmalig eingegeben.
#97
FHEMWEB / Aw: Claude.ai Problem mit Anfa...
Letzter Beitrag von betateilchen - 24 November 2025, 12:43:54Zitat von: Invers am 24 November 2025, 12:32:19Auch das hattest du gestern veröffentlicht und ich verbitte mir so etwas.
Auch die nahträgliche Löschung macht das nicht ungesagt.
Schön, dass Du das gelesen hattest und sofort wusstest, wer gemeint ist.
Getroffene Hunde bellen. Meistens sogar, bevor sie mit dem Nachdenken begonnen haben.
Übrigens: ich stehe zu 100% zu meiner gestern getroffenen Aussage.
#98
MQTT / Aw: [GELÖST Bitte im FAQ übern...
Letzter Beitrag von safakspeyer - 24 November 2025, 12:32:46Internals:
BUF
CFGFN
DEF 192.168.178.122:1883 mqttClient testuser test2
DeviceName 192.168.178.122:1883
FUUID 69243983-f33f-c789-55ec-bcf68e59cd40620b
NAME mqttClient
NR 329
STATE disconnected
TYPE MQTT2_CLIENT
WBCallback
clientId mqttClient
connecting 1
lastMsgTime 1763982846.52591
nextOpenDelay 5
READINGS:
2025-11-24 12:23:00 state disconnected
msquitto isat auf dem homeassistant installiert und der fhem auf dem nas
Ich bekomme einfach die Verbindung nicht hin
Logs
025.11.24 12:31:03 1: 192.168.178.122:1883 disconnected, waiting to reappear (mqttClient)
2025.11.24 12:31:04 1: 192.168.178.122:1883 reappeared (mqttClient)
kann mir jemand bitte helfen
Attributes:
BUF
CFGFN
DEF 192.168.178.122:1883 mqttClient testuser test2
DeviceName 192.168.178.122:1883
FUUID 69243983-f33f-c789-55ec-bcf68e59cd40620b
NAME mqttClient
NR 329
STATE disconnected
TYPE MQTT2_CLIENT
WBCallback
clientId mqttClient
connecting 1
lastMsgTime 1763982846.52591
nextOpenDelay 5
READINGS:
2025-11-24 12:23:00 state disconnected
msquitto isat auf dem homeassistant installiert und der fhem auf dem nas
Ich bekomme einfach die Verbindung nicht hin
Logs
025.11.24 12:31:03 1: 192.168.178.122:1883 disconnected, waiting to reappear (mqttClient)
2025.11.24 12:31:04 1: 192.168.178.122:1883 reappeared (mqttClient)
kann mir jemand bitte helfen
Attributes:
#99
FHEMWEB / Aw: Claude.ai Problem mit Anfa...
Letzter Beitrag von Invers - 24 November 2025, 12:32:19Zitat von: betateilchen am 23 November 2025, 21:50:19Auch das hattest du gestern veröffentlicht und ich verbitte mir so etwas. Auch die nahträgliche Löschung macht das nicht ungesagt. Zitat: Umso mehr, wenn solche seitenlangen "Vorschläge" von Menschen gepostet werden, die zwar regelmä0ig nicht in der Lage sind, die einfachsten Dinge von FHEM zu verstehen, aber es durchaus schaffen, ein Sprachmodell mit gezielten Informationen zu füttern, um solche Ergüsse zu erhalten... Sehr eigenartig.Zitat von: rudolfkoenig am 23 November 2025, 17:08:47Patches werde ich nicht uebernehmen.
Aus eigener Erfahrung muss ich die Loesung selbst finden bzw. erstellen, sonst kann ich die Software nicht mehr warten.
Dem schließe ich mich vollumfänglich an.
Wenn es jetzt hier losgeht, dass man sich als Entwickler gegen irgendwelchen zusammengenerierten Mist aus dem Internet "verteidigen" muss, wird es über kurz oder lang dazu führen, dass man die Lust verliert, noch irgendwas zu FHEM beizutragen.
#100
FHEMWEB / Aw: Claude.ai Problem mit Anfa...
Letzter Beitrag von Invers - 24 November 2025, 12:28:18Zitat von: passibe am 24 November 2025, 05:45:06Vor kurzem war OP selbst diesbezüglich noch etwas kritischer unterwegs:Das betraf aber nur die Leistung zjm damaligen Problem. Es war nicht als generelle Verurteilung der KIs gemeint. Diesmal hat es halt für MICH geholfen. Ich habe den Code in meine Additional CSS übernommen und es funtkioniert wieder alle. Für mich ist das Beweis genug. Ob es irgendwo gepatcht wird, oder nicht, ist mir daher relativ egal, das muss immer der Moduleigentümer bestimmen. Vielleicht hilft ja mein Beitrag jemandem, der dasselbe Problem hat.Zitat von: Invers am 03 November 2025, 21:27:18Die KI solte sich schämen und zwar alle. Google, Claude und der rest der Welt.