Neueste Beiträge

#1

Heizungssteuerung/Raumklima / Aw: Vitoconnect - Verbesserte ...

Letzter Beitrag von stefanru - 20 Januar 2026, 00:33:43

Hi Binlan,
oh wow da hat Viessmann wohl auch noch einige Leichen im Keller Bin froh dass es nun bei dir geht.
Gut aber immerhin haben wir auf V3 Authentifizierung umgestellt und auch sonst scheint die Version bei uns beiden gut zu laufen.
Werde sie morgen so ins SVN übernehmen.


Hi Jo,
da kannst du nur bei Viessmann im Forum Nachfragen und hoffen er wird bald geliefert. Laut EU Data Act müssen sie ja gewisse Readings liefern.

Gruß,
Stefan

[Device‑Definition]

#2

Anfängerfragen / Aw: Nuki 4.0 pro für MQTT Anbi...

Letzter Beitrag von cryptik - 19 Januar 2026, 22:24:48

Hallo zusammen,

ich möchte hier meine funktionierende Konfiguration für das Nuki 4.0 Pro via MQTT2_DEVICE teilen.
Enthalten sind:

vollständiges Reading‑Mapping

saubere State‑Übersetzung (numerisch + string)

Icon‑Set für alle Tür‑Zustände

Homebridge‑Mapping


Vielleicht hilft es jemandem, der ebenfalls das neue Nuki 4.0 Pro per MQTT einbindet.

Device‑Definition

Code Auswählen Erweitern

defmod Nuki_SN MQTT2_DEVICE Nuki_SN
attr Nuki_SN alias FLU_Tuerschloss

attr Nuki_SN devStateIcon \
geschlossen:smartlock_locked@green \
offen:smartlock_unlocked@red \
öffnet:smartlock_unlocked@blue \
schließt:smartlock_locked@blue \
falle_geöffnet:smartlock_unlocked@red \
blockiert:general_warning@yellow \
undefiniert:general_question@grey

attr Nuki_SN event-min-interval battery:3600
attr Nuki_SN event-on-change-reading .*
attr Nuki_SN genericDeviceType lock
attr Nuki_SN icon nuki_lockjavascript:void(0);
attr Nuki_SN room 01_Wohnraum->Flur,Homekit

MQTT Reading‑Zuordnung

Code Auswählen Erweitern

Nuki_SN:nuki/SN/connected:.* connected
Nuki_SN:nuki/SN/timestamp:.* timestamp
Nuki_SN:nuki/SN/deviceType:.* deviceType
Nuki_SN:nuki/SN/name:.* name
Nuki_SN:nuki/SN/firmware:.* firmware
Nuki_SN:nuki/SN/batteryChargeState:.* batteryChargeState
Nuki_SN:nuki/SN/batteryCritical:.* batteryCritical
Nuki_SN:nuki/SN/batteryCharging:.* batteryCharging
Nuki_SN:nuki/SN/keypadBatteryCritical:.* keypadBatteryCritical
Nuki_SN:nuki/SN/doorsensorBatteryCritical:.* doorsensorBatteryCritical
Nuki_SN:nuki/SN/state:.* state
Nuki_SN:nuki/SN/mode:.* mode
Nuki_SN:nuki/SN/serverConnected:.* serverConnected
Nuki_SN:nuki/SN/lockActionEvent:.* lockActionEvent
Nuki_SN:nuki/SN/commandResponse:.* commandResponse

Hinweis: 
Ersetze SN durch deine echte Nuki‑Seriennummer.
Ich habe es hier neutral gehalten.

State‑Mapping (stateFormat) (numerisch + string → deutsch)

Code Auswählen Erweitern

{
  my %map = (
    # numerische Nuki-States
    0   => "unkalibriert",
    1   => "geschlossen",
    2   => "öffnet",
    3   => "offen",
    4   => "falle_geöffnet",
    5   => "falle_geöffnet",
    7   => "schließt",
    254 => "blockiert",
    255 => "undefiniert",

    # string-basierte Nuki-States
    "lock"         => "geschlossen",
    "locking"      => "schließt",
    "unlock"       => "öffnet",
    "unlocking"    => "öffnet",
    "unlatch"      => "falle_geöffnet",
    "unlatching"   => "falle_geöffnet",
    "motorblocked" => "blockiert",
    "undefined"    => "undefiniert"
  );

  my $v = ReadingsVal($name, "state", "255");
  return $map{$v} // $v;
}

Homebridge‑Mapping

Code Auswählen Erweitern

clear
LockCurrentState=state,values=1:SECURED;2:SECURED;3:UNSECURED;4:UNSECURED;5:UNSECURED;7:SECURED;254:JAMMED;255:UNKNOWN;lock:SECURED;locking:SECURED;unlock:UNSECURED;unlocking:UNSECURED;unlatch:UNSECURED;unlatching:UNSECURED;motorblocked:JAMMED;undefined:UNKNOWN
LockTargetState=state,values=1:SECURED;3:UNSECURED;4:UNSECURED;2:UNSECURED;7:UNSECURED;lock:SECURED;unlock:UNSECURED;unlatch:UNSECURED,cmds=SECURED:lock;UNSECURED:unlatch

Hinweis zum Homebridge‑Mapping (unlatch vs. unlock)
HomeKit unterstützt beim Türschloss nur zwei Aktionen:

SECURED → abschließen

UNSECURED → aufschließen

Das Nuki kennt jedoch zusätzlich die Funktion ,,Falle öffnen" (unlatch), also das tatsächliche Öffnen der Tür.

Da HomeKit kein eigenes Kommando für ,,Falle öffnen" besitzt, mappe ich in meinem Setup:

UNSECURED → unlatch

Das bedeutet:
Wenn ich die Tür über HomeKit ,,aufschließe", führt das Nuki unlatch aus, also aufschließen + Falle ziehen.
Das ist für meinen Anwendungsfall ideal, weil ich die Tür über HomeKit nicht nur entriegeln, sondern wirklich öffnen möchte.

Wer nur entriegeln möchte, kann stattdessen:

UNSECURED → unlock

verwenden.

[Alle 15sec.]

#3

Sonstige Systeme / Aw: Support-Thread Modul 36_Sh...

Letzter Beitrag von JoergBo - 19 Januar 2026, 22:23:38

Hi,
ich habe für eine Fehlersuche Stacktrace aktiviert. Den ursprünglichen Fehler habe ich gefunden.
Sobald Stacktrace aktiviert ist, taucht ein weiterer Fehler auf, der nichts mit meinem gesuchten Fehler zu tun hat.
 
Alle 15sec. taucht diese Meldung im Log auf:

Code Auswählen Erweitern

2026.01.19 21:49:29 1: PERL WARNING: Use of uninitialized value $comp in concatenation (.) or string at ./FHEM/36_Shelly.pm line 4940.
2026.01.19 21:49:29 1: stacktrace:
2026.01.19 21:49:29 1:    main::__ANON__                      called by ./FHEM/36_Shelly.pm (4940)
2026.01.19 21:49:29 1:    main::Shelly_status2G              called by ./FHEM/36_Shelly.pm (7615)
2026.01.19 21:49:29 1:    main::Shelly_HttpResponse          called by FHEM/HttpUtils.pm (756)
2026.01.19 21:49:29 1:    main::__ANON__                      called by fhem.pl (786)
2026.01.19 21:49:29 1: PERL WARNING: Use of uninitialized value $comp in string eq at ./FHEM/36_Shelly.pm line 4941.
2026.01.19 21:49:29 1: stacktrace:
2026.01.19 21:49:29 1:    main::__ANON__                      called by ./FHEM/36_Shelly.pm (4941)
2026.01.19 21:49:29 1:    main::Shelly_status2G              called by ./FHEM/36_Shelly.pm (7615)
2026.01.19 21:49:29 1:    main::Shelly_HttpResponse          called by FHEM/HttpUtils.pm (756)
2026.01.19 21:49:29 1:    main::__ANON__                      called by fhem.pl (786)
2026.01.19 21:49:29 1: PERL WARNING: Use of uninitialized value $comp in string eq at ./FHEM/36_Shelly.pm line 4958.
2026.01.19 21:49:29 1: stacktrace:
2026.01.19 21:49:29 1:    main::__ANON__                      called by ./FHEM/36_Shelly.pm (4941)
2026.01.19 21:49:29 1:    main::Shelly_status2G              called by ./FHEM/36_Shelly.pm (7615)
2026.01.19 21:49:29 1:    main::Shelly_HttpResponse          called by FHEM/HttpUtils.pm (756)
2026.01.19 21:49:29 1:    main::__ANON__                      called by fhem.pl (786)

FHEM und 36_Shelly.pm sind aktuell, ich habe viele verschiedene Shellys hier im Einsatz.
Da das die einzigen Log Einträge sind, habe keine Idee wonach ich suchen soll.

Jemand einen Hinweis für mich, was ich tun kann?

#4

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 19 Januar 2026, 21:58:42

Ah, ok. Mach ich.

#5

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von 300P - 19 Januar 2026, 21:57:21

Edit: Oder meinst du dass man mehrere Versionen sichern kann?

Ja - das war mein Anliegen 

Ich habe am RPI eine 1 TB Platte und sichere mir da 14 Tage

#6

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 19 Januar 2026, 21:51:10

Kannst du evtl. die Datei des Traininglaufes in deine Backuproutine operatingMemory dort noch mit einbauen ?

Das ist schon passiert denn die KI Daten müssen ja einen FHEM Restart überleben.
Du/ihr findet das beste bzw. verwendete Trainingsergebnis im File

../FHEM/FhemUtils/NeuralNet_SolarForecast_<Name>

Und wird beim Start geladen:

2026.01.19 20:47:15.626 3: SolCast - cached data "pvHistory" restored
2026.01.19 20:47:15.644 3: SolCast - cached data "pvCircular" restored
2026.01.19 20:47:15.646 3: SolCast - cached data "consumerMaster" restored
2026.01.19 20:47:15.646 3: SolCast - cached data "radiationApiData" restored
2026.01.19 20:47:15.647 3: SolCast - cached data "statusApiData" restored
2026.01.19 20:47:15.648 3: SolCast - cached data "weatherApiData" restored
2026.01.19 20:47:15.694 3: SolCast - cached data "aiRawData" restored
2026.01.19 20:47:15.703 3: SolCast - cached data "NeuralNetwork" restored

Fehlt vermutlich noch im Wiki.

Edit: Oder meinst du dass man mehrere Versionen sichern kann?

#7

Anfängerfragen / Aw: Update bricht mit Fehler a...

Letzter Beitrag von enno - 19 Januar 2026, 21:50:36

Moin

ich denke das gehört hier zu: https://wiki.fhem.de/wiki/Ntfy

mit

Code Auswählen Erweitern

update delete https://rm.byterazor.de/upd-fhem-ntfy/controls_byterazor-fhem-ntfy.txt

Könnte dass Problem lösen.

Gruss
  Enno

#8

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von 300P - 19 Januar 2026, 21:43:58

@Heiko
Kannst du evtl. die Datei des Traininglaufes in deine Backuproutine operatingMemory dort noch mit einbauen ?

#9

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von 300P - 19 Januar 2026, 21:25:34

Abhilfe wäre z.B. ein "Füllsensor" der Schmutzwäsche. Ab x% wird der Wama Betrieb wahrscheinlich ....

Bei mir ist das im Winter bei WAMA und Trocken. :
Abhängigkeit von der Länge der Werbung die in meinem ausgewählten TV-Programm läuft.
Wenn mir diese auf den Wecker geht und ich mich daran erinnere das ich den Korb am Morgen in die Treppe gestellt habe mache ich eine Wäsche...     

Ob das dann eine weiße 90 Grad Kochwäsche / 30 Grad hell oder dunkel oder weiß / 30 Wolle ohne schleudern / oder 60 Grad Wäsche oder ein Trocknerlauf wird kann ich erst dann sagen wenn die Wäsche sortiert wird.
Zusätzlich kommt dann noch möglicher PV-Überschuss in Betracht - aber seit der WP gibt es das nicht mehr im Winterhalbjahr bei mir. 

Im Sommer lade ich einfach die Maschine voll die grade dran ist und lasse SF dann am nächsten Morgen entscheiden wann sie losläuft und wann sie unterbricht. Ich hole nur kurz nach Mittag die Wäsche raus auf die Leine zum draußen trockenen.  

Wer jetzt sich jetzt noch fragt wann ich unser Haus mit den 115 m2 putze - ja Montags 1 OG - Dienstags im EG - auch da habe ich jede Woche einen anderen Ablauf und einen anderem Umfang - je nachdem was ich für eine Arbeitswut habe und was mir vor die Füße fällt bzw. grade als notwendig einfällt.    .
Dafür benötigte dann zwischen 4-6 Latte Macchiato - da könnte ich auch eine kleines Steckdosen EM dazwischen stecken.


So genug geträumt....      


Lustigen Abend noch       

#10

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 19 Januar 2026, 20:19:41

Nabend zusammen,

das ist ja eine rege Diskussion ... 

Nun ist es so, dass für die Berechnung der Heizkurve (d.h. Abweichung SOLL zu IST) eben diese Durchschnittstemperatur verwendet wird, für die Wärmeleistung, die die Wärmepumpe gerade liefern kann, ist aber die tatsächliche Außentemperatur relevant.

Was macht für die KI nun Sinn "bekanntzumachen"?

Ihr lasst am Besten nur die gemessene Temperatur mitteilen. Diese Werte werden für jede Stunde in den Rohdaten gespeichert. Daraus werden dann aber 1h / 3h Deltas oder bei Bedarf und Feature-Implementierung rollierende 3h / 6h oder 12h Durchschnitte der KI zur Verfügung gestellt. Das passiert aber alles bei der Semantik/Feature-Implementierung die ich gemeinsam mit euch baue und testen... Schritt für Schritt.

Was ist künftig mit der Kühlung über die Wärmepumpe? Auch die habe ich in einem separaten Gerät abgebildet. Zum Einen, weil die Leistungsaufnahme im Kühlbetrieb höher ist, und zum Anderen um der Prognose die Chance zu geben die Abhängigkeiten richtig zu lernen.
Allerdings - und das ist der große Unterschied zum Heizen - ist der Kühlbetrieb da auch "ein", wenn der Verdichter nicht läuft:
Im Kühlbetrieb wird permanent das Wasser durch die Kühlkreise gepumpt, der Verdichter schaltet zyklisch ein, um es abzukühlen. Ein/Aus über "swstate" zu erkennen, wäre dann eher kontraproduktiv, weil das die Info zum Stromverbrauch ad absurdum führt. Hierfür wäre dann doch die Schwelle des Energiebedarfs sinnvoll, von mir aus auch eine Kombination aus beidem?

Ja, genau eine Kombination. Auch wenn der heatpump-Consumer ein paar Besonderheiten hat, gelten die grundsätzlichen Schlüssel-Möglichkeiten. Also hier speziell der pcurr-Schlüssel, den man mit einem <Schwellenwert> (W) angeben kann, ab dem der Verbraucher als aktiv gewertet wird. Über swstate bekommt das Modul mit dass der Consumer "physisch" on/off ist und über den optionalen Schwellenwert ob er logisch! on/off ist.

Für die WP bedeutet es mit Schwellenwert:

- swstate = on -> Schwellenwert überschritten ? Ja -> WP ist "on" , ? Nein -> WP ist "off"
- swstate = off -> WP ist "off"

Für die KI bitte nicht zwei getrennte Heiz- und Kühl-Consumer anlegen, sondern einfach nur eine WP. In den Lerndatensätzen gibt es dann Verknüpfungen von Temperaturen im Vergleich mit der Komforttemperatur sowie jahrezeitliche Zusammenhänge und mehr.

Für mich ist noch nicht klar, wie die realen Werte der Energie in den KI-Algorithmus eingehen. Stellt die aktuelle Gesamtleistung die Berechnungsgrundlage dar oder fließen die einzelnen Verbraucher - also nicht nur type=heatpump - mit ihren jeweils aktuell anstehenden Leistungen getrennt ein?

Das ist generell ein schwieriges Thema. Grundsätzlich kann man dem neuronalen Netz nur Verknüpfungen/Sematiken bereitstellen, die das Verhandensein eines bestimmten Energieverbrauchs erklären. Das sind zum Beispiel:

- Tageszeiten
- Anwesenheiten
- Batterieladezustände
- Temperaturen
- PV Ertrag
- PV Prognose
- Jahreszeiten
- Feiertage, Arbeitstage, Wochenende
- Vorhandensein von WP, EV
- Sonnenstände
- ....

Aus diesen Dingen implementiere ich noch zusätzliche Signale wie diese:

Code Auswählen Erweitern

# --------------------------------------------------------
# Semantik: Menschlicher Tagesrhythmus (PV-unabhängig)
# --------------------------------------------------------
semantics_human_rhythm => sub {
    my ($f) = @_;
    return [
        # --- MORGEN ---
        softplus($f->{delta1_norm_pos} * $f->{hour_class_morning}),             # Aufstehen / Geräte an

        # --- MITTAG ---
        softplus($f->{delta1_norm_pos} * $f->{hour_class_noon}),                # Kochen / Haushalt

        # --- ABEND ---
        softplus($f->{delta1_norm_pos} * $f->{hour_class_evening}),             # Kochen / Abendaktivität

        # --- SPÄTER ABEND ---
        softplus($f->{delta1_norm_neg} * $f->{hour_class_lateevening}),         # Geräte gehen aus
    ];
},

Das sind keine Berechnungsvorschriften, aber sie sagen beispielsweise es sind gerade Morgenstunden (hour_class_morning) und es gibt ein Ansteigen des stündlichen Energieverbrauchs in den Trainingsdaten (delta1_norm_pos) dann stehen die Bewohner typischerweise auf und machen sich Kaffee und Toastbrot. Das ist nur ein Signal im Normierungsbereich 0...1 oder -1 ... 1 je nach verwendeter Aktivierungsfunktion (mit oder ohne SYMMETRIC).
Ob die KI diesen "Hinweis" von mir Beachtung schenkt und daraus etwas lernt und welche Gewichtung sie dieser Information beimisst kann ich weder beeinflussen noch wissen. Nur durch Einbau, Testtraining und Auswertung der Kennzahlen erkennt man ob die Maschine lernt.

Wie schon mehrfach erwähnt sind Waschmaschine und Trockner echte Störenfriede weil ich einfach kein semantisches Zusatzsignal generieren kann. Es gibt weder Temperatur noch Tages/Jahreszeitabhängigkeiten. Das passiert einfach und die KI kann es nicht vorhersehen. Abhilfe wäre z.B. ein "Füllsensor" der Schmutzwäsche. Ab x% wird der Wama Betrieb wahrscheinlich ....
Aktuell wird duch die Trendfolge-Logik ein Ausgleich geschaffen.

Bei getrennter Erfassung könnte die Auswertung von EIN/AUS-Signalen auch anderer großer Verbraucher durch die eindeutige Zuordnung der Verbräuche die Mustererkennung und damit die Treffsicherheit der Prognose für die Wärmepumpe aber auch insgesamt u U. weiter verbessern.

Absolut. Allerdings bräuchte man dann wieder Zusammenhänge wann diese anderen Großverbraucher üblicherweise in Betrieb gehen, siehe Wama und Trockner.
Gut umsetzbar wäre aber z.B. ein Heizstab für Warmwasser. Hier gäbe es gute Zusammenhänge mit Wassertemperatur, PV Ertrag, Tageszeit und Wochentag/WE.


Genau solche Zusatzinformationen versuche ich jetzt für EV zusammenzustellen und einzubauen um dann daraus Profile wie oben zu sehen zu gestalten. Dazu gehören noch Anwesenheiten, Feiertagskalender und solche Dinge.
Es ist ein sehr weites Feld. Dagegen ist die PV Vorhersage mit KI relativ einfach weil von relativ wenigen Größen der Wetterdienste und Geometrien abhängig.