Neueste Beiträge

#1

InterTechno / Fenstermelder nicht erkannt -...

Letzter Beitrag von roli - 01 März 2026, 17:59:03

Also ich habe eine BUSWARE  Cul  mit Version : V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) nanoCUL433 (F-Band: 433MHz)

Eigentlich funktioniert alles soweit hervorragend - Nur, bekomme ich mal unterschiedliche Sensoren von China geliefert, die
wohl nicht erkannt werden.

Es ist mir aber nicht klar, ob ich diese überhaupt in FHEM so definieren kann, dass eine korrekte Verarbeitung erfolgt.
Ich habe 6 Fenstersensoren bestellt und 1 wird nicht erkannt :

Folgendes liefert mir FHEM unter CUL verbose 4:
 

Code Auswählen Erweitern




2026.03.01 16:00:32 4: CUL_Parse: nanoCUL433 i0C10460B -68.5
2026.03.01 16:00:32 4: nanoCUL433 IT: message "i0c1046" (7)
2026.03.01 16:00:32 4: nanoCUL433 IT: msgcode "00100F00F0FD" (12) bin = 000011000001000001000110
2026.03.01 16:00:32 3: nanoCUL433: Unknown code i0c1046, help me!

Im Eventlog sehe ich :    CUL nanoCUL433 UNKNOWNCODE i0c1046


Gleicher Typ von Sensor welcher erfolgreich funktioniert liefert :

Code Auswählen Erweitern

define    FN_Funk_3   IT      1527x0b732  0110 0000   


2026.03.01 17:11:58 4: CUL_Parse: nanoCUL433 i0B732618 -62
2026.03.01 17:11:58 4: nanoCUL433 IT: message "i0b7326" (7)
2026.03.01 17:11:58 4: nanoCUL433 IT: msgcode "" (0) bin = 000010110111001100100110




In einem Arduino 433mzh Empfangs-Sketch  erhalte ich folgendes:

Code Auswählen Erweitern


[b]Sensor 1 ( in FHEM nicht erkannt ):[/b]
 > (24Bit)  Binary: 000011000001000001000110
  Decimal: 790598  HEX: C1046
  Tri-State: not applicable
  PulseLength: 421 microseconds Protocol: 1
  Raw data: 1164,396,1192,396,1192,400,1188,400,1184,1140,448,1140,448,424,1172,416,1172,420,1172,416,1172,420,1168,1140,448,416,1160,440,1160,416,1164,436,1160,424,1168,1144,440,428,1168,408,1180,420,1160,1148,448,1144,432,432,1168,

[b]Sensor 2 ( in FHEM erkannt und funktioniert  ):[/b]

-> (24Bit)  Binary: 000010110111001100100110
  Decimal: 750374  HEX: B7326
  Tri-State: not applicable
  PulseLength: 421 microseconds Protocol: 1
  Raw data: 8608,776,1676,256,1324,760,2408,384,1200,1116,456,2964,244,16,1204,376,1176,428,1168,400,1200,1116,444,340,1264,1116,468,1116,440,584,1116,468,1120,464,404,1184,400,360,516,2164,144,404,1184,404,1172,1152,436,1132,460,


 

Frage:
   * Kann ich den Sensor irgendwie aufsetzen, damit er In FHEM auch funktioniert?

Alle anderen Sensoren funktionieren mit z.B.:

    define    FN_Funk_1   IT      1527x2040f  0110 0000


Verwende ich :

   define    FN_Funk_1   IT      1527xc1046  0110 0000

so erhalte ich :

CUL nanoCUL433 UNKNOWNCODE i0c1046


Keine Ahnung was da falsch läuft

#2

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 01 März 2026, 17:34:41

@Markus,

wie kann man die consumer Steuerung global deaktivieren?

Das geht momentan nicht.
Aber ich kann eine solche Möglichkeit über consumerControl->XXX einbauen wenn gewünscht.

Soll die Möglichkeit gegeben sein, die Steuerungsinfo über ein externes Reading bereitzustellen oder reicht ein klassischer Attributwert dafür?

LG,
Heiko

#3

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 01 März 2026, 17:27:58

Nicht traurig sein  ... es ist besser diesen Parameter als Pflichtangabe zu definieren und ein userReading "in Kauf" zu nehmen als irgendwann eine freiwillige Angabe doch als verpflichtend umzuwidmen weil es ohne eben nicht geht. Vielleicht ergibt sich ja später die Möglichkeit über Hilfswerte doch noch das Ziel auf anderem Wege zu erreichen was ich zum aktuellen Zeitpunkt aber noch nicht beurteilen kann.

#4

DOIF / DOIF reagiert verzögert auf sc...

Letzter Beitrag von holle75 - 01 März 2026, 16:59:17

zu dem hier entstandenen -> https://forum.fhem.de/index.php?topic=142783.msg1351980#msg1351980

und jetzt so (oder immer noch) aussenden DOIF RAW

Code Auswählen Erweitern

defmod XtenderSet_Max_Solar DOIF ([$SELF:ZuBerechnendeGesamtleistung] > 800 and [$SELF:ZuBerechnendeGesamtleistung] > [$SELF:ZuBerechnendeGesamtleistung_old] and [$SELF:ZuBerechnendeGesamtleistung] <= 2000)\
    (set MQTT2_openDTU limit_absolute [$SELF:ZuBerechnendeGesamtleistung])\
DOELSEIF ([$SELF:ZuBerechnendeGesamtleistung] > 0 and [$SELF:ZuBerechnendeGesamtleistung] <= 2000)\
    (set MQTT2_openDTU limit_absolute [$SELF:ZuBerechnendeGesamtleistung])
attr XtenderSet_Max_Solar devStateIcon disabled:general_aus@red:initialize initialize:general_an@yellow:disable initialized:general_an@yellow:disable cmd_1.*:general_an@green:disable cmd_2.*:general_an@green:disable
attr XtenderSet_Max_Solar do resetwait
attr XtenderSet_Max_Solar event-on-change-reading ZuBerechnendeGesamtleistung,ZuBerechnendeGesamtleistung_old
attr XtenderSet_Max_Solar event_Readings ZuBerechnendeGesamtleistung: {(2800 - [Studer485_VT:PV_Power_W]) > 2000 ? 800 : (2800 - [Studer485_VT:PV_Power_W])}
attr XtenderSet_Max_Solar group System_2
attr XtenderSet_Max_Solar oldreadings ZuBerechnendeGesamtleistung,oldreadingsAlways
attr XtenderSet_Max_Solar room Xtender
attr XtenderSet_Max_Solar sortby 4
attr XtenderSet_Max_Solar stateFormat state\
<br>\
ZuBerechnendeGesamtleistung
attr XtenderSet_Max_Solar userReadings ZuBerechnendeGesamtleistung_old:ZuBerechnendeGesamtleistung.* { OldReadingsVal("XtenderSet_Max_Solar", "ZuBerechnendeGesamtleistung", "0") }
attr XtenderSet_Max_Solar wait 10:0
irritiert mich folgendes ... alle meine DOIF´s kann ich über das devStateIcon in der Weboberfläche schalten. DIESES Doif verzögert ca 10 Sekunden und wird dann erst bei reload/refresh der Page mit dem aktuellen Status angezeigt. Die anderen machen das sofort. Hat es etwas mit den event_Readings zu tun, oder hat noch jemand eine andere Erklärung?

attr XtenderSet_Max_Solar stateFormat state\
<br>\
ZuBerechnendeGesamtleistung

hatte ich auch schon versuchsweise gelöscht, ohne Änderung des Verhaltens

[Revision 30895: 76_SolarForecast: contrib Version 2.2.2]

#5

FHEM Code changes / Revision 30895: 76_SolarForeca...

Letzter Beitrag von System - 01 März 2026, 16:01:04

Revision 30895: 76_SolarForecast: contrib Version 2.2.2

76_SolarForecast: contrib Version 2.2.2

Source: Revision 30895: 76_SolarForecast: contrib Version 2.2.2

#6

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von Parallix - 01 März 2026, 15:49:24

...

Vielleicht bin ja der einzige mit o.g. Problem. Dann werde ich ein Dummy schreiben, welches für SF einen fiktiven SOC auf Basis früherer Verbrauchswerte bestimmt.

#7

Anfängerfragen / Aw: Homekit zur Überwachung

Letzter Beitrag von Guybrush - 01 März 2026, 15:42:41

Devices zu überwachen kannst du z.b. mit Watchdog gut umsetzen. Hier mal ein Beispiel für die Überwachung meiner Klimasteuerung:

Code Auswählen Erweitern

defmod Essen.Klima.Watchdog watchdog Essen.Klima:mode:.* 00:15:00 SAME setreading OfflineDevices device-$NAME offline
attr Essen.Klima.Watchdog userattr notifyMessage
attr Essen.Klima.Watchdog DbLogExclude .*
attr Essen.Klima.Watchdog activateOnStart 1
attr Essen.Klima.Watchdog autoRestart 1
attr Essen.Klima.Watchdog group Watchdog
attr Essen.Klima.Watchdog room Interfaces->MQTT,Überwachung

bei mir wird das dann in das Dummy Device "OfflineDevices" geschrieben, wenn es länger als 15 Minuten keine aktualisierten Readings im Device gibt. Da läuft dann ein DOIF alle paar Minuten drüber, überprüft das und benachrichtigt mich falls nötig. Da kannst du dann aber auch alles andere machen, was du für dich brauchst. Ich hab bei den kritischen Sachen wie z.b. Wasserleckage etc noch zusätzlich Sprachdurchsagen über Sonos und Whatsapp Nachricht eingebaut.

Die HomeApp, von der du schreibst, sagt mir nichts. Aber grundsätzlich geht es bei sowas, was du suchst, nur drum bei events ein passendes reading zu beschreiben und darauf dann z.b. ein DOIF oder notify zu setzen

#8

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 01 März 2026, 15:27:25

@Parallix,

Der Ladebedarf kann praktisch immer aus dem Neuanstecken eines BEV an der Wallbox abgeleitet werden. Der Energiemenge sollte sich aus früheren Ladevorgängen abschätzen lassen.

Das gilt vllt. für den initialen Bedarf, jedoch nicht für eine Fortschreibung die den Ladebedarf kontinuierlich neu bewertet - Unterbrechungen und Phasenreduktionen inklusive.
Außerdem würde es voraussetzen, dass der Ladebedarf bei jeder Ladesession immer nahezu gleich bleiben würde. Das bezweifle ich. Wenn es so simpel ist, braucht es eigentlich keinerlei Messungen mehr und wir schätzen nur noch.

Hierzu braucht man übrigens nicht einmal eine KI: Jeder Mensch, der ein Kraftfahrzeug führt, kennt seinen üblichen Wochen oder Monatsverbrauch oder kann diesen leicht durch Summation der Tankquittungen bestimmen.

Wenn es so einfach ist, kann man ein userReading mit diesem Wert anlegen welches ich konsumieren kann.
Dann steht auch der Pflichtangabe nichts im Wege.

Und auch die beste KI kann nicht erahnen, in welcher Woche man z.B. zu einem Konzert fährt, für das man Tickets ergattert hat oder ob und wann man im laufenden Jahr in Urlaub fährt. Hier hilft ein Klick auf einen entsprechenden Button seines FHEM-Dashboards/Control-Panels oder das dortige Eintragen des Urlaubszeitraums sicher und - geeignete Modellierung vorausgesetzt - auch sehr präzise.

Kann sie nicht, aber sehr wohl den E-Bedarf der nächsten Stunden schätzen wenn das EV angesteckt ist und der StartSOC sowie die Bat-Kapazität -> Ziel-Soc bekannt ist.

#9

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 01 März 2026, 15:20:13

Ich habe noch etwas an der contrib nachgebessert und hochgeladen.

#10

Anfängerfragen / Aw: readingsGroup commands mit...

Letzter Beitrag von Guybrush - 01 März 2026, 14:27:39

ich hab mir den Programmcode nun mal selbst angeschaut und so wie ich das sehe geht das nicht. Ich hab das nun für mich in die 33_readingsGroup.pm so angepasst, wie ich es brauchte. Dazu sollte aber besser mal justme1968 was sagen, da er die geschrieben hat.

Folgendes hab ich gemacht, damit man zumindest einfache Vergleiche anhand des Values machen und den link entsprechend dynamisch setzen kann.

In der 33_readingsGroup.pm hab ich folgende Funktion eingebaut:

Code Auswählen Erweitern

sub readingsGroup_valueCheck($) {
    my ($value) = @_;

    $value =~ m/VALUE\(\s*'.*?'\s*\)/g;
    my $res = $&;

    if ($res) {

        my @str = split(/VALUE\(\s*'.+?\s*'\)/, $value);

        $res =~ s/VALUE\(\s*'//;
        $res =~ s/'\s*\)//;
        my @value = split(/','/, $res);

        return $str[0].($value[0] eq $value[1] ? $value[2] : $value[3]).$str[1] if (scalar(@value) == 4);
    }
}

dazu hab ich dann in der Datei alle Variablen "$value_prefix" ersetzt durch "readingsGroup_valueCheck($value_prefix)".

in fhem selbst habe ich dann statt des Attributs commands nun das Attribut valuePrefix gesetzt. In meinem Fall so:

Code Auswählen Erweitern

attr OfflineDevices.RG valuePrefix <a style="cursor:pointer" onclick="FW_cmd('/fhem?XHR=1&cmd=setreading %DEVICE %READING VALUE('%VALUE','offline','confirmed','offline')')">

als valueSuffix muss natürlich noch "</a>" gesetzt werden, aber das sollte selbstverständlich sein.

so kann ich den Wert in der readingsGroup nun jederzeit zwischen offline und confirmed togglen ohne erst ins device gehen zu müssen. Wenn jemand eine einfachere Lösung hat, dann bitte gerne her damit. Ich finde es auch nicht so prickelnd in einer von fhem verwalteten Datei rumzufuschen, aber anders wusste ich jetzt nicht, wie es umzusetzen wäre und feedback gabs ja bislang keins 

Vielleicht kann Justme1968 dazu auch mal was sagen.