- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#41
MQTT / Aw: MQTT2-Server und Retain
Letzter Beitrag von rudolfkoenig - 15 März 2026, 11:22:45ZitatFrage: ist das so beim MQTT2-Server von FHEM? Aktiviert der standartmäßig ein Retaining? Wenn ja, warum und kann man das deaktivieren?Retain ist bei MQTT2_SERVER per Voreinstellung deaktiviert, weil es mehr Probleme schafft, als es loest.
Man kann es mit dem respectRetain Attribut wieder aktivieren, siehe https://fhem.de/commandref_modular.html#MQTT2_SERVER-attr-respectRetain
#42
Homematic / Aw: HM-SEC-SCO nach Exclude ne...
Letzter Beitrag von Otto123 - 15 März 2026, 11:17:44Hallo Dan,
beim reset meinst Du die erste Beschreibung?
Das ist ja einer wo das Rücksetzen mehrstufig ist.
Gruß Otto
beim reset meinst Du die erste Beschreibung?
ZitatZur Bestätigung des Zurücksetzens leuchtet die LED
für etwa 3 Sekunden dauerhaft rot auf.
Mögliche Fehlermeldungen:
Dieser Fehler kann nur auftreten, wenn der Sensor an eine Zentrale angelernt wurde.
Beginnt die LED nach 5 Sekunden Gedrückthalten
nicht zu blinken, sondern leuchtet dauerhaft auf, kann
der Sensor nicht zurückgesetzt werden. In diesem Fall
unterscheidet sich der Auslieferungsschlüssel vom
System-Sicherheitsschlüssel. Setzen Sie den Sensor
über die WebUI Bedienoberfläche zurück. Weitere Informationen finden Sie im WebUI Handbuch (zu finden
im Downloadbereich unter www.homematic.com).
Das ist ja einer wo das Rücksetzen mehrstufig ist.
Gruß Otto
#43
MQTT / MQTT2-Server und Retain
Letzter Beitrag von rih - 15 März 2026, 11:14:12Ich habe ein Problem mit dem Shelly plus uni, dessen Stati per MQTT gemeldet werden. Konkret geht es um die 2 Eingänge des Shelly:
Wenn der oder die Eingänge beim Start / Neustart des Shelly bereits "on" sind (auf GND geschaltet sind), dann werden diese zwar nach dem Hochlauf im Webinterface des Shelly korrekt als "on" angezeigt, die entsprechenden Eingangs-Readings im MQTT-Device in FHEM werden aber als "off" angezeigt. Erst nach einem Schalterwechsel aus/ein sind auch die Readings wieder synchron.
Der Shelly-Support ist der Meinung, dies würde am MQTT-Boker liegen, der mit dem Shelly ein Retain aushandeln würde.
Frage: ist das so beim MQTT2-Server von FHEM? Aktiviert der standartmäßig ein Retaining? Wenn ja, warum und kann man das deaktivieren?
Wenn der oder die Eingänge beim Start / Neustart des Shelly bereits "on" sind (auf GND geschaltet sind), dann werden diese zwar nach dem Hochlauf im Webinterface des Shelly korrekt als "on" angezeigt, die entsprechenden Eingangs-Readings im MQTT-Device in FHEM werden aber als "off" angezeigt. Erst nach einem Schalterwechsel aus/ein sind auch die Readings wieder synchron.
Der Shelly-Support ist der Meinung, dies würde am MQTT-Boker liegen, der mit dem Shelly ein Retain aushandeln würde.
Frage: ist das so beim MQTT2-Server von FHEM? Aktiviert der standartmäßig ein Retaining? Wenn ja, warum und kann man das deaktivieren?
#44
FHEMWEB / Aw: VoiceButton für Fhemweb
Letzter Beitrag von rudolfkoenig - 15 März 2026, 11:03:52Das Firefox Problem habe ich jetzt in Prinzip (s.u.) gefixt.
Zum Aktivieren muss in about:config media.webspeech.recognition.enable auf true gesetzt werden.
Dann oeffnet sich das Dialog, nach Sprachaufnahme kommt aber die Meldung: Error connecting to the service.
Chrome@Android meldet bei mir nichtmal Audio started, keine Ahnung, was da falsch laeuft.
Die Doppelung der Texte lag vielleicht an stt.interimResults=true, das habe ich jetzt entfernt.
Bei mir hat das keinen Unterschied bewirkt.
Die anderen Punkte:
- eine eindeutige Zuordnung des Clients ist kein Problem, will aber (mit dem Rest auch) abwarten, welchen Weg wir gehen wollen
- Sprachausgabe ist laut Doku moeglich, habs aber nicht getestet
- Dialog veraltet: ich habe gerne ein Feedback, solange die Erkennung nicht perfekt ist. Was schwebt Dir vor?
HTTPS mit einem gueltigen Zertifikat hat den Vorteil, dass man damit eine WebApp installieren kann, was wiederum Benachrichtigungen empfangen kann (ungetestet).
Weiss (noch) nicht, ob man damit auch Sprachausgabe ausloesen kann, bin eher skeptisch.
Gueltige Zertifikate kann man auch selbst erstellen, das Zertifikat muss auf dem Client dann installiert werden.
Zum Aktivieren muss in about:config media.webspeech.recognition.enable auf true gesetzt werden.
Dann oeffnet sich das Dialog, nach Sprachaufnahme kommt aber die Meldung: Error connecting to the service.
Chrome@Android meldet bei mir nichtmal Audio started, keine Ahnung, was da falsch laeuft.
Die Doppelung der Texte lag vielleicht an stt.interimResults=true, das habe ich jetzt entfernt.
Bei mir hat das keinen Unterschied bewirkt.
Die anderen Punkte:
- eine eindeutige Zuordnung des Clients ist kein Problem, will aber (mit dem Rest auch) abwarten, welchen Weg wir gehen wollen
- Sprachausgabe ist laut Doku moeglich, habs aber nicht getestet
- Dialog veraltet: ich habe gerne ein Feedback, solange die Erkennung nicht perfekt ist. Was schwebt Dir vor?
HTTPS mit einem gueltigen Zertifikat hat den Vorteil, dass man damit eine WebApp installieren kann, was wiederum Benachrichtigungen empfangen kann (ungetestet).
Weiss (noch) nicht, ob man damit auch Sprachausgabe ausloesen kann, bin eher skeptisch.
Gueltige Zertifikate kann man auch selbst erstellen, das Zertifikat muss auf dem Client dann installiert werden.
#45
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von 300P - 15 März 2026, 10:58:53Die Peaks kommen (glaub ich) eher von der Wärmepumpe bei der 2-maligen täglichen WW-Aufbereitung (ab ca. 04:00 Uhr. und meist meist gegen 12:00 Uhr )
(Screenshot gestern / heute)
(Screenshot gestern / heute)
#46
Solaranlagen / Aw: Modul für Ecoflow-Komponen...
Letzter Beitrag von Cineman - 15 März 2026, 10:52:29Hallo! Ich bin neu in diesem Forum und hoffe auf Eure Hilfe, obwohl ich kein FHEM-Nutzer bin (aktuell versuche ich meine Einbindung über n8n und in mein laufendes Openhab-System).
Ich besitze eine Stream Ultra und Stream AC Pro. Bisher ist mir mit den Jinweisen in diesem Forum gelungen die GET-Befehle umzusetzen. Ein herzlichen Dank für diese Infos! Jedoch schaffe ich es keine PUT oder POST Befehle zu senden. Ist das schon jemandem gelungen? Und wenn ja, wie?
Ich besitze eine Stream Ultra und Stream AC Pro. Bisher ist mir mit den Jinweisen in diesem Forum gelungen die GET-Befehle umzusetzen. Ein herzlichen Dank für diese Infos! Jedoch schaffe ich es keine PUT oder POST Befehle zu senden. Ist das schon jemandem gelungen? Und wenn ja, wie?
#47
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von 300P - 15 März 2026, 10:49:13Zitat von: DS_Starter am 15 März 2026, 10:13:52Die andere Sache ... zeige mal bitte den Wert von pvInverterCapSum aus "get .. valCurrent".
pvInverterCapSum => 9500
Code Auswählen
aiConActFunc => GAUSSIAN_SYMMETRIC
aiConActivate => 1
aiConAlpha => 0.7
aiConBitFailLimit => 0.23
aiConHiddenLayers => 80-40
aiConLearnRate => 0.001
aiConMomentum => 0.6
aiConProfile => v1_heatpump_active_pv
aiConShuffleMode => 1
aiConShufflePeriod => 20
aiConSteepness => 1.0
aiConTrainAlgo => INCREMENTAL
aiConTrainStart => 30:3
aiLastGetResultTime => 0.00075
aiStorageDuration => 3600
aiTrainStart => 3
aiTreesPV => 30
aicanuse => ok
aitrainstate => ok
aitrawstate => ok
allStringsFullfilled => 1
allstringscount => 6
allstringspeak => 14610
allstringspeakbytemp => 15720
animate => 1
autarkyrate => 100
backupFilesKeep => 14
batRatio01 => 16.29
batRatio02 => 34.79
batcapsum => 24428
batpowerinsum => 524
batpoweroutsum => 0
batsocslidereg => 3.45 3.45 3.45
batsoctotal => 3.45
batteryPreferredCharge => 30
batwhdeficitsum => 23585
batwhtotal => 843
beamHeightlevel => 1:200,2:200,3:200
cachefilesloaded => 1
conNNGetResultState => ok
conNNLastGetResultTime => 0.08532
conNNTrainstate => ok
consForecastIdentWeekdays => 0
consForecastInPlanning => 1
consForecastLastDays => 14
consumerCollected => 1
consumerdevs => FBDECT_fbahahttp_11657_0127183 FBDECT_fbahahttp_E8_DF_70_07_3E_57 FBDECT_fbahahttp_11657_0067275 FBDECT_fbahahttp_34_31_C4_D4_31_37 FBDECT_fbahahttp_E8_DF_70_07_42_0B SMA_Elgris_EM2 MQTT_EMSwp
consumerdist => 130
consumption => 1937
ctrunning => 0
cycleInterval => 15
dayAfterTomorrowConfc => 34631
dayAfterTomorrowPVfc => 16959
dummyConsumption => 497.15
dummyIcon => status_comfort@#ff8c00
dwdRad1hAge => 2026-03-15 09:00:00
dwdRad1hAgeTS => 1773561600
dwdRad1hDev => DWD
dwdWfchAge => 2026-03-15 10:41:41
dwdWfchAgeTS => 1773567701
eFeedInTariff => 0.08123
eFeedInTariffCcy => €
ePurchasePrice => 0.25
ePurchasePriceCcy => €
feedinPowerLimit => 6000
genPVdeviation => continuously
genPVforecastsToEvent => adapt4Steps
genslidereg => 2442 2440 2471
globalMode => unset
gridconsumption => 0
gridfeedin => 10
h2consumerdist => 50
h4fcslidereg => 12000 12000 12000
headerDetail => all
heatpumpInstalled => 08
homenodedyncol => 1
hourCount => 24
layoutType => double
moonPhaseI => 7
nextCycleTime => 1773567955
outsideTemp => 5.9
pvInverterCapSum => 9500
runTimeCentralTask => 1.59033
runTimeLastAPIAnswer => 1.1396
runTimeLastAPIProc => 0.3542
scaleMode => 1:lin,2:lin
selfconsumption => 1937
selfconsumptionrate => 78
setupcomplete => 1
shiftx => 0
shifty => 0
showDiff => 1:bottom,2:bottom
showGenerators => 1
showLink => 1
showconsumer => 1
showconsumerdummy => 1
showconsumerpower => 1
showconsumerremaintime => 1
size => 600
smoother => OTP => Battery_ChargeOptTargetPower_01 => ALPHA => 1
CHANGED => 0
DEADBAND => 10
NEWVAL => 2500
OBJ => FHEM::SolarForecast::Smoother=HASH(0x55a4452fb0)
OLD => 2500
SMOOTHED => 2500
Battery_ChargeOptTargetPower_02 => ALPHA => 1
CHANGED => 0
DEADBAND => 10
NEWVAL => 2000
OBJ => FHEM::SolarForecast::Smoother=HASH(0x55a44531f0)
OLD => 2000
SMOOTHED => 2000
strokeCmrRedColLimit => 500
strokeconsumerdyncol => 1
strokewidth => 12
sunriseToday => 2026-03-15 06:44:00
sunriseTodayTs => 1773553440
sunriseTomorrowTs => 1773639660
sunsetToday => 2026-03-15 18:32:00
sunsetTodayTs => 1773595920
sunsetTomorrowTs => 1773682380
surplus => 534
surplusslidereg => 615 283 411 918 653 591 588 516 422 516 471 484 515 386 467 445 654 557 537 534
tdConFcTillSunset => 11890
tdConFcUp2Now => 17464
tdPvFcUp2Now => 3952
tmConFcTillSunset => 30344
tmConInHrWithPVGen => 23485
tomorrowconsumption => 40688 #48
FHEM Code changes / Revision 30956: f18.js: fix ST...
Letzter Beitrag von System - 15 März 2026, 10:41:04Revision 30956: f18.js: fix STT for FireFox (Forum #144147)
f18.js: fix STT for FireFox (Forum: #144147)
Source: Revision 30956: f18.js: fix STT for FireFox (Forum #144147)
f18.js: fix STT for FireFox (Forum: #144147)
Source: Revision 30956: f18.js: fix STT for FireFox (Forum #144147)
#49
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 15 März 2026, 10:13:52Guten Morgen,
die Vorzeichenänderung bei DriftBias kommt durch
my $bias_drift = $bias_model - $bias_live;
Das ist richtig. Ansonsten ist die Driftberechnung - hier maßgeblich durch BiasLive=1518.76 - durch die Berücksichtigung eines 96h Fensters beeinflusst. D.h. einmalige Ausreißer, bei mir durch Wama und Trockner verursacht, führen zu einer übermäßig langen Blockierung (Block=unstable_bias) der Drift-Rekalibrierung.
Dieses Fenster habe ich inzwischen auf 24h geändert, was die Rekal wesentlich aktiver werden lässt. Lade ich noch hoch wenn noch nicht geschehen.
Die andere Sache ... zeige mal bitte den Wert von pvInverterCapSum aus "get .. valCurrent".
die Vorzeichenänderung bei DriftBias kommt durch
my $bias_drift = $bias_model - $bias_live;
Das ist richtig. Ansonsten ist die Driftberechnung - hier maßgeblich durch BiasLive=1518.76 - durch die Berücksichtigung eines 96h Fensters beeinflusst. D.h. einmalige Ausreißer, bei mir durch Wama und Trockner verursacht, führen zu einer übermäßig langen Blockierung (Block=unstable_bias) der Drift-Rekalibrierung.
Dieses Fenster habe ich inzwischen auf 24h geändert, was die Rekal wesentlich aktiver werden lässt. Lade ich noch hoch wenn noch nicht geschehen.
Die andere Sache ... zeige mal bitte den Wert von pvInverterCapSum aus "get .. valCurrent".
#50
FHEMWEB / Aw: VoiceButton für Fhemweb
Letzter Beitrag von Beta-User - 15 März 2026, 09:53:09Zitat von: schwatter am 15 März 2026, 08:54:52- Zu Dialog führen. Kann der Text nicht einfach per notify an Rhasspy weitergereicht werden?RHASSPY hat eine NotifyFn() und setzt -abängig von der Konfiguration- NOTIFYDEF derzeit maximal auf "TYPE=(AMADCommBridge|AMADDevice|ROOMMATE|GUEST),global"
AMAD.* ist der "historische" Weg, um über TTS-Ereignisse und das Ende von Sprachausgaben informiert zu werden, ROOMMATE und GUEST dienen zum Chatten (hier via Telegram). In allen Fällen wird "angefragter Text" dann an Rhasspy bzw. die dortige Intent-Auswertung übergeben und das Ergebnis dann wieder in FHEM verarbeitet, alles selbstredend asynchron. RHASSPY "merkt" sich dabei, wohin ggf. dann welche Rückmeldung von Rhasspy zu senden ist, so dass auch - theoretisch - viele parallele Sitzungen möglich sind.
Zitat von: schwatter am 15 März 2026, 08:54:52- Ich finde FHEMWEB nicht ideal. Besser sowas wie global. Das ist leichter bei mehreren FHEMWEB's. Ein Knotenpunkt. Deswegen habe ich den dummy.Für meine Zwecke ist es letztlich egal, wo das Event ausgelöst wird. Das NOTIFYDEF auf TYPE=FHEMWEB auszuweiten wäre jedenfalls kein Problem, und auch (in den meisten Installationen) begrenzter als alle dummy-TYPE-Instanzen mit auszuwerten. Events an "global" (zusätzlich anders) auszuwerten ginge selbstredend auch.
Unabhängig davon: AMADCommBridge nimmt die TTS-Info entgegen UND auch die Info, von welcher AMADDevice-Instanz die Anfrage stammt. So kann RHASSPY die zu sprechende Antwort genau dahin schicken, wo die Anweisung ursprünglich her war. (Für ROOMMATE|GUEST ist es sowieso klar).
Für meine Zwecke MUSS es also in jedem Fall eine zweite Info geben, wohin die Antwort (bzw. ggf. Rückfrage...) gesendet werden soll.
"Schön" wäre es, wenn auch das Ende einer von FHEM ausgelösten Sprachausgabe signalisiert werden könnte, und dafür erscheint mir "global" nicht der passende Ort zu sein; das ist bei FHEMWEB schon schwierig, weil da ja mehrere Sitzungen offen sein können...