- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#91
Sprachsteuerung / Aw: Alexa Thermometer interpre...
Letzter Beitrag von KyleK - 21 November 2025, 22:37:10Das ist in der Tat ein "Alexa"-Problem: https://de.amazonforum.com/s/question/0D5at00000Ly8ICCAZ/alexa-sagt-kein-minus-vor-der-temperatur-mehr-an
Selbst bei Ansagen die Amazon/Alexa selbst generieren (z.B. auf "wie wird heute das Wetter") verschluckt Alexa das Minus.
Selbst bei Ansagen die Amazon/Alexa selbst generieren (z.B. auf "wie wird heute das Wetter") verschluckt Alexa das Minus.
#92
Anfängerfragen / SolarForecast Fehlermeldung im...
Letzter Beitrag von Hackstall - 21 November 2025, 21:03:05Hallo ich habe in meinem Log folgende Fehlermeldungen:
Kann mir hier jemand weiterhelfen was zu tun ist:
2025.11.21 20:57:44.317 1: Forecast - ERROR in Application - attribute ctrlSpecialReadings KPI '
conForecastTillNextSunrise' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2025.11.21 20:57:44.318 1: Forecast - ERROR in Application - attribute ctrlSpecialReadings KPI '
currentRunMtsConsumer_04' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2025.11.21 20:57:44.318 1: Forecast - ERROR in Application - attribute ctrlSpecialReadings KPI '
daysUntilBatteryCare_01' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2025.11.21 20:57:44.318 1: Forecast - ERROR in Application - attribute ctrlSpecialReadings KPI '
runTimeAvgDayConsumer_01' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2025.11.21 20:57:44.318 1: Forecast - ERROR in Application - attribute ctrlSpecialReadings KPI '
runTimeAvgDayConsumer_05' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2025.11.21 20:57:44.319 1: Forecast - ERROR in Application - attribute ctrlSpecialReadings KPI '
runTimeLastAPIProc' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2025.11.21 20:57:44.319 1: Forecast - ERROR in Application - attribute ctrlSpecialReadings KPI '
todayConsumptionForecast' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2025.11.21 20:57:44.320 1: Forecast - ERROR in Application - attribute ctrlSpecialReadings KPI '
todayRemainingAPIcalls' has no Parameter or default value set. Set the attribute again or inform Maintainer.
Kann mir hier jemand weiterhelfen was zu tun ist:
2025.11.21 20:57:44.317 1: Forecast - ERROR in Application - attribute ctrlSpecialReadings KPI '
conForecastTillNextSunrise' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2025.11.21 20:57:44.318 1: Forecast - ERROR in Application - attribute ctrlSpecialReadings KPI '
currentRunMtsConsumer_04' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2025.11.21 20:57:44.318 1: Forecast - ERROR in Application - attribute ctrlSpecialReadings KPI '
daysUntilBatteryCare_01' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2025.11.21 20:57:44.318 1: Forecast - ERROR in Application - attribute ctrlSpecialReadings KPI '
runTimeAvgDayConsumer_01' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2025.11.21 20:57:44.318 1: Forecast - ERROR in Application - attribute ctrlSpecialReadings KPI '
runTimeAvgDayConsumer_05' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2025.11.21 20:57:44.319 1: Forecast - ERROR in Application - attribute ctrlSpecialReadings KPI '
runTimeLastAPIProc' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2025.11.21 20:57:44.319 1: Forecast - ERROR in Application - attribute ctrlSpecialReadings KPI '
todayConsumptionForecast' has no Parameter or default value set. Set the attribute again or inform Maintainer.
2025.11.21 20:57:44.320 1: Forecast - ERROR in Application - attribute ctrlSpecialReadings KPI '
todayRemainingAPIcalls' has no Parameter or default value set. Set the attribute again or inform Maintainer.
#93
Heizungssteuerung/Raumklima / Aw: LAN-Anbindung für BSB-Bus ...
Letzter Beitrag von freetz - 21 November 2025, 20:33:29Freut mich, dass es geklappt hat - wenn es fertig ist und läuft, teile es gerne hier, dann würde ich schauen, ob ich den Shelly-Eintrag im Wiki entsprechend erweitere.
#94
Off-Topic / Aw: Mein gar nicht so "dünner"...
Letzter Beitrag von betateilchen - 21 November 2025, 20:05:49Inzwischen habe ich in die Kiste spaßeshalber einen Dual-port-SAS Controller eingebaut.
Damit könnte ich jetzt extern bis zu 8 Festplatten anschließen...
Unter Debian als Basis für Proxmox wird der Controller problemlos auf Anhieb erkannt.
Jetzt muss ich mich mal auf die Suche nach einem "hübschen" Festplattengehäuse machen, das man sich auch gerne ins Arbeitszimmer stellt, wenn es nicht nach "Rechenzentrum" aussehen soll.
---
Damit könnte ich jetzt extern bis zu 8 Festplatten anschließen...
Unter Debian als Basis für Proxmox wird der Controller problemlos auf Anhieb erkannt.
Code Auswählen
01:00.0 Serial Attached SCSI controller: Broadcom / LSI SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 03)Jetzt muss ich mich mal auf die Suche nach einem "hübschen" Festplattengehäuse machen, das man sich auch gerne ins Arbeitszimmer stellt, wenn es nicht nach "Rechenzentrum" aussehen soll.
---
#95
Anfängerfragen / Aw: Grafisch Gas Statistik
Letzter Beitrag von betateilchen - 21 November 2025, 19:56:03Zitat von: Sebastian84 am 21 November 2025, 15:27:48Finde ich unter FileLog das Device nicht wo ich den Tagesverbrauch her bekomme
Zitat von: Prof. Dr. Peter Henning am 21 November 2025, 16:55:34Das ist etwas wirr.
@pah: mit ziemlicher Sicherheit ist damit die dropdown-Liste gemeint, die von den eventTypes gefüllt wird. Da steht am Anfang der Zeile im gplot-Editor immer "FileLog" als Quelle.
#96
Codeschnipsel / Aw: [MiniChart]Fhemweb Widget ...
Letzter Beitrag von schwatter - 21 November 2025, 19:43:14Nabend,
ich habe den ersten Beitrag bearbeitet. Unter Punkt 2 findet ihr jetzt ein Fhemweb Widget für Minichart.
Enthalten sind Linechart und Barchart. Wie üblich nach /opt/fhem/www/pgm2 kopieren. Eigentümer:Fhem, Gruppe:dialout.
Optisch fast wie vorher. lediglich die Umrandung ist erstmal weg.
Beispiel:
Gruß schwatter
ich habe den ersten Beitrag bearbeitet. Unter Punkt 2 findet ihr jetzt ein Fhemweb Widget für Minichart.
Enthalten sind Linechart und Barchart. Wie üblich nach /opt/fhem/www/pgm2 kopieren. Eigentümer:Fhem, Gruppe:dialout.
Optisch fast wie vorher. lediglich die Umrandung ist erstmal weg.
Beispiel:
Code Auswählen
attr Smartmeter_2E1F50 webCmd test
attr Smartmeter_2E1F50 widgetOverride test:minichart,Jetzt@APOX_Power@W,Total ;In@APOX_E_in@kWh,Total ;Out@APOX_E_out@kWh,chartArray,bar@red@#3FD62D
Code Auswählen
| Abschnitt | Bedeutung | Beschreibung |
| --------------------------------- | ------------------------ | ------------------------------------------------------------------------------------------------------- |
| <beliebigerName> | webCmd-Zuweisung | Gibt an, auf welches webCmd das Widget zugreift. |
| minichart | Widget-Typ | Initialisiert das Minichart-Widget. |
| Jetzt@APOX_Power@W | Reading | Labelname Jetzt, Reading APOX_Power, Einheit W. |
| Total In@APOX_E_in@kWh | Reading | Labelname Total In, Reading APOX_E_in, Einheit kWh. |
| Total Out@APOX_E_out@kWh | Reading | Labelname Total Out, Reading APOX_E_out, Einheit kWh. |
| chartArray | Reading (Chart-Daten) | Datenquelle für das Diagramm; liefert Array-Werte zur Darstellung. |
| bar@red@#3FD62D | Chart-Typ / Farben | Diagrammtyp. Es gibt "bar" und "line", sowie zwei Farbangaben. |
Gruß schwatter
#97
Sonstige Systeme / Es spukt, oder die Geister, di...
Letzter Beitrag von uli-bs - 21 November 2025, 19:05:26Moin,
ich habe hier ein Problem, bei dem ich mal einen Denkanstoß brauche.
Hier läuft auf einem RaspPi (3) eine recht alte (outdated) FHEM Installation, die bisher aber alles so gemacht hat wie ich wollte.
Mit MAX!, MQTT für Tasmota/ESPhome Devices und eben diversen Shellys für Licht und Rollläden, da hat sich nichts verändert.
Nun sind hier praktisch ausschließlich Shellys (FW 1.14) der ersten Generation verbaut (1er, Plugs, Dimmer, 2.5er) und letztere haben durch den defekten Elko angefangen zu spinnen. Soweit die Vorgeschichte.
Der Erste war der 2.5 vom Rollo in der Küche, das fuhr zwischendurch manchmal unmotiviert wieder hoch (Default bei "Power on") -> Elko getauscht, alles wieder gut.
Dann machte, rund 2 Wochen später, das Rollo im Wohnzimmer denselben Spaß, das Ding deaktiviert und einen "Sack" Elkos bestellt...
Jetzt trat zusätzlich der Effekt auf, dass alle möglichen Gerätschaften, die über Shellys gesteuert werden, ein Eigenleben entwickelten. Alle andere Geräte und auch die Shelly, die auf Tasmota umgeflasht sind, sind "gesund".
Lampen gingen nach Belieben z.T. in schneller Folge ein/aus, Rollos (3 mit Shelly-Steuerung) fuhren auf/ab, stoppten willkürlich, alles ohne erkennbaren Grund. Auch bei den betroffenen Devices ist nicht unbedingt ein System erkennbar.
Mittlerweile sind bei allen 2.5ern die Elkos getauscht (3 von 4 waren mehr oder weniger kapazitätsarm), aber an dem beschriebenen "Ghosting" ist keine Änderung erkennbar.
Die Verbindungen nach außen (Alexa und Remotezugriff) habe ich natürlich auch testweise unterbunden und auf Systemseite auch (schon davor) "fail2ban" installiert um den Systemschutz zu erhöhen, die lokalen PCs (Virus) kann ich ebenfalls ausschließen.
Aber irgend etwas triggert die Shellys, die führen die entsprechenden Befehle aus und melden dann, lt. interner Debuginformation, den Status auch an FHEM zurück.
Einzige sinnvolle Erkenntnis, die ich habe, ein Reboot oder "shutdown restart" löst das Problem für kurze Zeit (0,5 - 1 Std.), dann triggert das Schalten eines der Geräte den "Spaß" wieder.
In den FHEM-Logs habe ich nichts gefunden was mich weiterbringt, darum jetzt hier die Frage nach Ideen...
Was mir nicht hilft, ist das System auf einen aktuellen Stand zu bringen, das ist zwar geplant, aber es lief bisher über Jahre, genauso wie es eben ist. Weitere Informationen bitte gern nachfragen.
Und meinen Respekt für das Lesen des langen Textes.
ich habe hier ein Problem, bei dem ich mal einen Denkanstoß brauche.
Hier läuft auf einem RaspPi (3) eine recht alte (outdated) FHEM Installation, die bisher aber alles so gemacht hat wie ich wollte.
Mit MAX!, MQTT für Tasmota/ESPhome Devices und eben diversen Shellys für Licht und Rollläden, da hat sich nichts verändert.
Nun sind hier praktisch ausschließlich Shellys (FW 1.14) der ersten Generation verbaut (1er, Plugs, Dimmer, 2.5er) und letztere haben durch den defekten Elko angefangen zu spinnen. Soweit die Vorgeschichte.
Der Erste war der 2.5 vom Rollo in der Küche, das fuhr zwischendurch manchmal unmotiviert wieder hoch (Default bei "Power on") -> Elko getauscht, alles wieder gut.
Dann machte, rund 2 Wochen später, das Rollo im Wohnzimmer denselben Spaß, das Ding deaktiviert und einen "Sack" Elkos bestellt...
Jetzt trat zusätzlich der Effekt auf, dass alle möglichen Gerätschaften, die über Shellys gesteuert werden, ein Eigenleben entwickelten. Alle andere Geräte und auch die Shelly, die auf Tasmota umgeflasht sind, sind "gesund".
Lampen gingen nach Belieben z.T. in schneller Folge ein/aus, Rollos (3 mit Shelly-Steuerung) fuhren auf/ab, stoppten willkürlich, alles ohne erkennbaren Grund. Auch bei den betroffenen Devices ist nicht unbedingt ein System erkennbar.
Mittlerweile sind bei allen 2.5ern die Elkos getauscht (3 von 4 waren mehr oder weniger kapazitätsarm), aber an dem beschriebenen "Ghosting" ist keine Änderung erkennbar.
Die Verbindungen nach außen (Alexa und Remotezugriff) habe ich natürlich auch testweise unterbunden und auf Systemseite auch (schon davor) "fail2ban" installiert um den Systemschutz zu erhöhen, die lokalen PCs (Virus) kann ich ebenfalls ausschließen.
Aber irgend etwas triggert die Shellys, die führen die entsprechenden Befehle aus und melden dann, lt. interner Debuginformation, den Status auch an FHEM zurück.
Einzige sinnvolle Erkenntnis, die ich habe, ein Reboot oder "shutdown restart" löst das Problem für kurze Zeit (0,5 - 1 Std.), dann triggert das Schalten eines der Geräte den "Spaß" wieder.
In den FHEM-Logs habe ich nichts gefunden was mich weiterbringt, darum jetzt hier die Frage nach Ideen...
Was mir nicht hilft, ist das System auf einen aktuellen Stand zu bringen, das ist zwar geplant, aber es lief bisher über Jahre, genauso wie es eben ist. Weitere Informationen bitte gern nachfragen.
Und meinen Respekt für das Lesen des langen Textes.
#98
FRITZ!Box / Aw: 72_FRITZBOX.pm ab Version...
Letzter Beitrag von neobiker - 21 November 2025, 18:44:48Zitat von: JoWiemann am 21 November 2025, 17:50:07Zitat von: neobiker am 21 November 2025, 17:33:31Hi Jörg,
diese Version funktioniert bei mir nicht, das Modul wird damit nicht geladen.
Hallo Neobiker, kommentier bitte einmal ganz am Anfang das Laden von xmlsimple aus.
Danke und Grüße Jörg
damit startet das Modul wieder
#99
Verbrauchsmessung / Aw: Tibber & Tibber Pulse
Letzter Beitrag von ch.eick - 21 November 2025, 18:18:00Hallo zusammen,
wie ja einige wissen, befasse ich mich mit der Vergleichsmöglichkeit von z.B. Tibber, aWattar und dem Grundversorger.
Meine Vorstellung wäre hierbei nur noch ein Device zu haben, dass aus dem EPEX Spot und den restlichen Teilkosten dann durch Umschalten die möglichst genauen Preise von Tibber und co zu berechnen. Um die Tibber Preise genau zu bekommen müsste man ja bereits Kunde sein. Bei aWattar sieht es sicherlich auch nicht viel besser aus.
Nun habe ich mal versucht rauszufinden welche einzelnen Teilkosten so alle anfallen und wie die EVUs dann die Preise darus berechnen. Es ist ein Horror, aber ich komme dem ganzen schon recht nah, da ich einen Tibber Kunden zum vergleichen habe
Das Device hat bisher folgende Attribute:
Zur Umschaltung bei der Berechnung wird ein reading gesetzt
conf_EVU [null|Tibber|aWattar]
Beim setzen des readings wird dann ein Basispreis pro kWh berechnet, bei dem dann bereits alles drin ist
conf_EVU_Summe_ct_kWh
Danach kann man den EXEX Spot abrufen und entsprechend der EVU Formel wird dann der Preis je kWh als Brutto Preis berechnet.
Bisher summiere ich die ct/kWh einfach auf und komme bereits recht nah an meinen Vergleichs Preis heran.
In dem aWattar Device habe ich jedoch eine andere Formel gefunden, bei der ich dann jetzt Eure Hilfe benötigen würde.
Was soll das " 0.03*abs($val) ", macht aWattar es sich einfach und berechnet einfach 3% Aufschlag?
Und was ist in den 1.785 enthalten.
VG Christian
wie ja einige wissen, befasse ich mich mit der Vergleichsmöglichkeit von z.B. Tibber, aWattar und dem Grundversorger.
Meine Vorstellung wäre hierbei nur noch ein Device zu haben, dass aus dem EPEX Spot und den restlichen Teilkosten dann durch Umschalten die möglichst genauen Preise von Tibber und co zu berechnen. Um die Tibber Preise genau zu bekommen müsste man ja bereits Kunde sein. Bei aWattar sieht es sicherlich auch nicht viel besser aus.
Nun habe ich mal versucht rauszufinden welche einzelnen Teilkosten so alle anfallen und wie die EVUs dann die Preise darus berechnen. Es ist ein Horror, aber ich komme dem ganzen schon recht nah, da ich einen Tibber Kunden zum vergleichen habe
Das Device hat bisher folgende Attribute:
Code Auswählen
# Der eigene Jahresverbrauch
conf_Netz_Jahresverbrauch_kWh
# Der aktuelle Steuersatz
conf_VAT 1.19
# Damit man nicht vergisst bei wem man im Netz ist
conf_VNB Mainzer Netze GmbH (64560)
# Die Kosten der EVUs
conf_EVU_Tibber_Grundgebuehr_EUR_Jahr
conf_EVU_Tibber_Zuschlag_ct_kWh
conf_EVU_aWattar_Grundgebuehr_EUR_Jahr
conf_EVU_aWattar_Zuschlag_ct_kWh
# Die Kosten des VNB
conf_VNB_Arbeitspreis_ct_kWh
conf_VNB_KWKG_ct_kWh
conf_VNB_Konzession_ct_kWh
conf_VNB_MSB_iMSys_EUR_Jahr
conf_VNB_MSB_mME_EUR_Jahr
conf_VNB_Messstelle mME <<< Das dient der Auswahl der Messstelle
conf_VNB_Netzentgelt_ct_kWh
conf_VNB_Paragraph_19_Umlage_ct_kWh
conf_VNB_Stromsteuer_ct_kWh
Zur Umschaltung bei der Berechnung wird ein reading gesetzt
conf_EVU [null|Tibber|aWattar]
Beim setzen des readings wird dann ein Basispreis pro kWh berechnet, bei dem dann bereits alles drin ist
conf_EVU_Summe_ct_kWh
Danach kann man den EXEX Spot abrufen und entsprechend der EVU Formel wird dann der Preis je kWh als Brutto Preis berechnet.
Bisher summiere ich die ct/kWh einfach auf und komme bereits recht nah an meinen Vergleichs Preis heran.
In dem aWattar Device habe ich jedoch eine andere Formel gefunden, bei der ich dann jetzt Eure Hilfe benötigen würde.
Was soll das " 0.03*abs($val) ", macht aWattar es sich einfach und berechnet einfach 3% Aufschlag?
Und was ist in den 1.785 enthalten.
Code Auswählen
round(($val + 0.03*abs($val) + 1.785)*1.19,2)
Gibt es da eine detailiertere Berechnung?VG Christian
#100
TabletUI / Aw: [FTUI3] Solarumgebung visu...
Letzter Beitrag von Tobias - 21 November 2025, 18:00:19Zitat von: setstate am 21 Mai 2025, 22:46:54Ein Beispiel gibt es unter examples/solar.html
Ich habe ein paar Fragen bzw Probleme mit dem Widget:
1. Kann es sein [battery-current] nicht mit mit einem negativen multiply(-1) umgehen kann?
Ohne multiply bzw mit einem positiven multiply und einem positiven Reading läuft in dem widget die Animation vom inverter zur Bat hoch. Da die Animation aber von der Bat zum Inverter herunter laufen soll wollte ich mit "| multiply(-1) " den wert ins negative schieben.
Problem ist dann aber, das die Animation nun in extremer Zeitlupe läuft von der Bat herunter zum Inverter läuft.
Code Auswählen
<ftui-solar-flow
[soc]="PlenticorePlus8:BatSOC | fix(0)"
[home-power]="PlenticorePlus8:_Verbrauch_aktuell_gesamt | multiply(1000) |fix(0)"
[grid-power]="KSEM:M_AC_Power | fix(0)"
[battery-current]="PlenticorePlus8:VerbrauchWbattery | multiply(-1)"
[grid-input-power]=""
[solar-power]="DOIF_PV_Summe:_Leistung_gesamt | round(0) | fix(0)"
[inverter-power]="PlenticorePlus8:Total_AC_Active_P | fix(0)"
>
</ftui-solar-flow>2. bei einem negativen Wert in [grid-power] läuft die Animation vom Grid hoch zum Inverter. Müsste die Animation nicht genau anders herum laufen??
3. ist der BatSoc exakt 100%, so wird nur 0% angezeigt. Ändere ich auf fix(1) auf eine Nachkommastelle so wird wieder 100.0% angezeigt. Scheint ein Bug zu sein.