Neueste Beiträge

#1
FHEM Code changes / Revision 31362: 36_Shelly.pm: ...
Letzter Beitrag von System - 15 Juni 2026, 23:00:40
Revision 31362: 36_Shelly.pm: add readings for prooutput addon

36_Shelly.pm: add readings for prooutput addon

Source: Revision 31362: 36_Shelly.pm: add readings for prooutput addon
#2
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 15 Juni 2026, 22:32:10
Nabend Gisbert,

wenn du deine erreichten Fehlermaße

MAE: 249.47 Wh
MedAE: 178.52 Wh
RMSE: 317.25 Wh
RMSE relative: 40 %
RMSE Rating: acceptable
MAPE: 33.11 %
MdAPE: 21.62 %
R²: 0.80

mit denen von 300P vergleichst:

Fehlermaße der Prognosen
MAE: 245.66 Wh
MedAE: 175.65 Wh
RMSE: 282.19 Wh
RMSE relative: 25 %
RMSE Rating: good
MAPE: 23.12 %
MdAPE: 14.65 %
R²: 0.83

siehst du dass die Ergebnsisse bei 300P gerade bei RMSE relative deutlich besser sind, 25% vs. 40%. Daraus folgt auch das Rating acceptable vs. good.
300P kann durch seine deutlich breitere Datenlage das spezifische WP-Profil nutzen, was bei dir wegen den doch noch "dünnen" Trainingsdaten noch nicht möglich ist. Aber das System wird über die eingebaute Drift-Korrektur in Grenzen gegensteuern.

Vergleich der Trainingsmetriken:

bei dir:
Validation MSE: 0.003750
Validation MSE Average: 0.003715
Validation MSE Standard Deviation: 0.000009

300P:
Validation MSE: 0.002347
Validation MSE Average: 0.002246
Validation MSE Standard Deviation: 0.000028

Korrektur: Meine Ersteinschätzung bezüglich der Standardabweichung war falsch, hier liegt dein System bezüglich der Standardabweichung in der Validierung vorn.

Meiner Meinung nach werden weitere Verbesserungen erst eintreten, wenn dein System mit mehr Daten trainieren kann und die WP-Features nutzen kann. In dem Zusammenhang wird es speziell für deinen Haushalt wichtig sein, dass ich die Möglichkeit mehrerer definierbarer WP sowie die schon andiskutierten opmodes realisiere.

Wahrscheinlich wirst du auch Änderungen in der CON-Prognose über die Zeit feststellen. Die Prognose ist dynamisch.
Mich würde ein Screenshot des Balkendiagramms mit Prognose/Ist interessieren.

LG,
Heiko
#3
Sonstige Systeme / Aw: Support-Thread Modul 36_Sh...
Letzter Beitrag von Starkstrombastler - 15 Juni 2026, 22:31:48
Zitat von: Flachzange am 15 Juni 2026, 20:05:13addon=prooutput
Ja, OK. Habe halt kein solches Teil hier bei mir zum Testen.

Mit dem nächsten Update sollten aber zwei Readings relay und source sichtbar sein.
#4
Server - Linux / Aw: [Docker / Container] echod...
Letzter Beitrag von Sidey - 15 Juni 2026, 22:23:17
Zitat von: FlatTV am 15 Juni 2026, 17:21:17Hallo Sidey,
erstmal - ,,haste gut gemacht".

Ein wenig irreführend ist noch, wer hier was macht.
Das ist ein Auszug aus dem fhem-Log
2026.06.15 10:50:35.919 3: [AlexaAccount] [echodevice_setState] to connected
2026.06.15 11:41:37.003 3: [AlexaAccount] [echodevice_setState] to connected
2026.06.15 12:02:18.333 3: [AlexaAccount] [echodevice_LoginStart] Alter COOKIE=56134/6000 Refresh Cookie!
2026.06.15 12:02:18.345 3: [AlexaAccount] [echodevice_NPMLoginRefresh] alexa-cookie modul not found
2026.06.15 12:11:24.226 3: [AlexaAccount] [echodevice_NPMWaitForCookie] [NPM Login Refresh Mon Jun 15 12:02:18 2026] write new refreshtoken
2026.06.15 12:25:37.959 3: [AlexaAccount] [echodevice_setState] to connected
2026.06.15 14:41:41.497 3: [AlexaAccount] [echodevice_setState] to connected

Der AlexaAccount steht ebenfalls auf intervallogin 57660.
Sollte man daran drehen oder fällt dir noch was schickes ein.

Das ist mir zunächst nicht aufgefallen :)  Ist bei mir aber exakt genau so, weil alle 6000 Sekunden das Alter vom gespeicherten cookie geprüft wird.

Den Intervall kann man seltsamerweise mit einem npm Attribut (hat mit npm nichts zu tun) ändern:
attr AlexaAccount npm_refresh_intervall 60060
Mit dem Attribut wird auch nicht direkt das refresh Intervall gesteuert, sondern das Mindestalter, bevor ein refresh ausgelöst wird.
Kurzum, wenn das Attribut größer als der zyklische refresh von acs ist, dann sollte es zu keiner Meldung im Log bei verbose 3 kommen.


Zitat von: FlatTV am 15 Juni 2026, 18:03:38Gibt es eigentlich ungefähr sowas schon?

FHEM/
 ├─ 98_Template.pm
 └─ templates/
     ├─ HTTPMOD/
     │   ├─ AlexaCookieService.cfg
     │   └─ irgendwas.cfg

So gibt es das leider derzeit nicht, wäre aber wirklich eine besser verwaltbare Lösung als die heutigen Templat Optionen..

Wenn wir einen stabilen Stand haben, kann ich ein Template für die Aufnahme vorschlagen.

Der Copy&Paste Ansatz ist aber aktuell auch nicht so übel finde ich für gefühlt ~3 Anwender.
#5
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von Gisbert - 15 Juni 2026, 21:59:48
Zitat von: DS_Starter am 15 Juni 2026, 12:55:41Hallo Gisbert,
dein letztes Training
14.06.2026    19:59:35.620    01:00    mySolarForecast    DEBUG>    Retry    attempt    2    with    Seed=21170366   
gefällt mir. Der Bit_Fail verringert sich kontinuierlich langsam von 17 auf 0.
Genauso verhält es sich auch mit Train MSE  und Val MSE. Beide Werte laufen gleichmäßig nach unten ohne auf einem Plateau-Wert hängen zu bleiben.
Und es werden 2911 Epochen verwendet, die der Berater gut finden sollte.
Für mich sieht das sehr gut aus und wenn du uns noch die Trainingsmetriken und Fehlermaße der Prognosen zeigen würdest, könnten wir einen Vergleich mit meinen (angehängten) oder den Werten von 300P im vorigen Post vergleichen.

Ich würde es so lassen und wenn du mehr Daten gesammelt hast und ich auch noch die zusätzlichen WP-Parameter eingebaut habe, kann man auch mal wieder einen Versuch mit einem WP-Profil starten.
@300P, wie ist deine Meinung dazu und zum Ergebnis?

LG,
Heiko

Hallo Heiko,

hier sind die weiteren Daten, Trainingsmetriken und Fehlermaße:

bestes Modell bei Epoche: 2911 (max. 15000)
Training MSE: 0.003947
Validation MSE: 0.003750
Validation MSE Average: 0.003715
Validation MSE Standard Deviation: 0.000009
Validation Bit_Fail: 0
Model Bias: 199 Wh
Model Slope: 0.81
Trainingsbewertung: ok

MAE: 249.47 Wh
MedAE: 178.52 Wh
RMSE: 317.25 Wh
RMSE relative: 40 %
RMSE Rating: acceptable
MAPE: 33.11 %
MdAPE: 21.62 %
R²: 0.80

Analysefenster: 96 h
Drift RMSE Ratio: 1.67
Semantic Ratio: 0.75
Slope Reference: 1.00
Slope Live: 0.62
Slope Drift: 0.620
Bias Reference: 0
Bias Live: 371.44
Bias Drift: 371.44
Score: 1.07
Index: 1.18
Drift Bewertung: low
Empfehlung für Retrain: keine keine
letzte Rekalibrierung: -

Wenn das Training für dich ok aussieht, wann kann ich denn mit einer Prognose in der Größenordnung des tatsächlichen Verbrauchs rechnen? Für morgen wird ein Verbrauch von 27.7 kWh prognostiziert, bei gleichbleibendem Verbrauch von 10~12 kWh.

Viele Grüße Gisbert
#6
Solaranlagen / Aw: Modul für Ecoflow-Komponen...
Letzter Beitrag von DS_Starter - 15 Juni 2026, 21:34:17
Vorige Woche Montag habe ich den API Zugang bzw. Developer Status bei EcoFlow beantragt damit ich das Modul nutzen kann. Bis jetzt kam keine Antwort.
Wie lange dauert das im Allgemeinen? Ggf. hat dabei etwas nicht geklappt.

LG,
Heiko
#7
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 15 Juni 2026, 21:29:17
Hallo Chris,

würde ich auch so machen wie 300P geschrieben hat.
Zur Ergänzung ... es können im Kopf der Grafik nur die Elemente aus setupEnvironment angezeigt werden.
Die Anzeige aktiviert man mit graphicControl->headerShowEnv.
#8
Hard- und Firmware / Aw: "unsaubere" Signale bei FM...
Letzter Beitrag von tostmann - 15 Juni 2026, 21:27:51
Hi DerD,

der Knackpunkt zuerst: Solange MDMCFG2 = 0x30 ist, läuft der CC1101 im ASK/OOK-Modus — und da ist DEVIATN laut Datenblatt schlicht wirkungslos (,,ASK/OOK: This setting has no effect."). Deshalb hat das Variieren der Deviation nichts gebracht: Du demodulierst ein FSK-Signal mit dem Amplitudendetektor, daher die verzerrten/asymmetrischen Pulse (FM-zu-AM über die Filterflanke). Zwei Dinge müssen stimmen — die richtige Frequenz und 2-FSK statt OOK. Als Startpunkt (Cw schreibt das CC1101-Register live, danach strobt der CUL selbst SCAL + RX):

set CUL raw Cw0D21     ; FREQ2   = 0x21  -> 868,95 MHz  (war 0x10 = 433,92!)
set CUL raw Cw0E6B     ; FREQ1   = 0x6B
set CUL raw Cw0FD1     ; FREQ0   = 0xD1
set CUL raw Cw1200     ; MDMCFG2 = 0x00  -> 2-FSK        (war 0x30 = ASK/OOK)
set CUL raw Cw1550     ; DEVIATN = 0x50  -> +/-50 kHz Hub
set CUL raw Cw1096     ; MDMCFG4 = 0x96  -> RX-BW 162 kHz + DRATE-Exp
set CUL raw Cw11CD     ; MDMCFG3 = 0xCD  -> DRATE ~2,86 kBaud

DEVIATN / RX-BW / DRATE sind nur Startwerte — die hängen an zwei Zahlen, die ich aus deinem Post nicht sicher ableiten kann. Kannst du in URH nachmessen:

- Tonabstand der beiden FSK-Frequenzen — und ist das der gesamte Abstand oder schon der Hub je Seite? Der CC1101 will den Hub (= halber Tonabstand).
- kürzeste Pulslänge / Symbolrate (deine 350 µs deuten auf ~2,86 kBaud).

Wichtig zur Einordnung: Der CUL/culfw hat keinen Eberle-Instat-Decoder — er kann dir nur den rohen demodulierten Bitstrom liefern (am GDO2-Pin, dein IOCFG2 = 0x0D = serial data out). Das Telegramm selbst (differentieller Manchester → Frame) musst du daraus rekonstruieren.

Für diesen Roh-Blick gibt es zwei Wege:

- Am saubersten: GDO2 direkt mit Logic-Analyzer/Scope abgreifen — dann siehst du den echten FSK-Demod-Strom 1:1 und kannst ihn neben URH legen (Firmware ist dabei egal, das macht der CC1101-Demodulator). Vermutlich machst du das ohnehin schon?
- Software-Alternative über culfw: der Monitor-Modus `set CUL raw X18` gibt die rohen Pulszeiten (r/f) über die serielle Schnittstelle aus. Das ist modulations-unabhängig, funktioniert also auch im FSK-Demod — allerdings als Binärwerte, über die FHEM-Konsole eher fummelig.

Wie greifst du die Pulse aktuell ab — GDO direkt oder über die culfw-Konsole?

Ausblick: SIGNALduino auf derselben Hardware ist für das FSK-Reverse-Engineering an sich die dankbarere Firmware (generischer FSK-Pfad, Register via W<reg><val>, FIFO-Empfang). ABER: seine rohen Pulslisten (MU) laufen nur im OOK-Modus — sobald MDMCFG2 auf FSK steht, schaltet es auf den FIFO-Empfang um, der ein bekanntes Sync-Word braucht. Für den jetzigen Schritt (rohen FSK-Strom ansehen) bringt es dir also noch nichts; es wird erst interessant, wenn du Sync-Word und Frame-Format kennst — dann holt es die Telegramme direkt als Hex aus dem FIFO. Bis dahin bist du mit GDO-Abgriff bzw. culfw-Raw besser dran.

Gruß
#9
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von 300P - 15 Juni 2026, 21:24:35
Dafür nutze doch attr <Name-SF-Device> graphicHeaderOwnspec

Hier "ein paar" mögliche Beispieleinträge:
#aiControl
ConActivate:aiControl->aiConActivate
ConAlpha:aiControl->aiConAlpha
ConTrainStart:aiControl->aiConTrainStart
:
#
ConActFunc:aiControl->aiConActFunc
ConHiddenLayers:aiControl->aiConHiddenLayers
ConLearnRate:aiControl->aiConLearnRate
ConMomentum:aiControl->aiConMomentum
#
ConShuffleMode:aiControl->aiConShuffleMode
ConShufflePeriod:aiControl->aiConShufflePeriod
ConSteepness:aiControl->aiConSteepness
ConTrainAlgo:aiControl->aiConTrainAlgo
#
ConProfile:aiControl->aiConProfile
ConBitFailLimit:aiControl->aiConBitFailLimit
ConAbsOversample:aiControl->aiConAbsOversample
ConTrainLimit:aiControl->aiConTrainLimit
#Drift
Drift&nbsp;Grund:userFn_DriftRetrainReason
Drift&nbsp;:userFn_DriftRetrainRecommendation
DriftFlag:userFn_DriftFlag
DriftSlopeLive:userFn_DriftSlopeLive
#Test
ConDriftTrafficLight:userFn_DriftTrafficLight
ConDriftAction:userFn_DriftAction
ConDriftAmpel:DriftAmpel
CentralTask:special_runTimeCentralTask
#WP-Warmwasser
Temperatur&nbsp;aktuell:boiler_data_dhw_curtemp@MQTT_EMSwp
aktuelle&nbsp;max&nbsp;Stoptemperatur:boiler_data_dhw_settemp@MQTT_EMSwp
Programm:thermostat_data_dhw_modetype@MQTT_EMSwp
Mode:thermostat_data_dhw_mode@MQTT_EMSwp
#10
ESP Familie / Aw: BoseFix32 — lokaler SoundT...
Letzter Beitrag von betateilchen - 15 Juni 2026, 21:07:40
Mach Dir keinen Stress.
Was jetzt schon alles geht, ist echt super. Danke dafür!

Ehrlich gesagt wäre mir eine 5GHz-Lösung persönlich wichtiger als die Display-Themen 🙃

Und ich hätte auch schon lange etwas gespendet, aber Paypal kommt mir nicht ins Haus.