Neueste Beiträge

#1

FHEMWEB / Aw: Anzeige plötzlich mit Fehl...

Letzter Beitrag von DerTom - 10 Dezember 2025, 12:30:27

Ich habe nach einem Update heute einen Fehler. Habe die alte Version wieder eingespielt und es lief wieder:

Code Auswählen Erweitern

2025.12.10 11:13:38.140 1: reload: Error:Modul 01_FHEMWEB deactivated: Variable length lookbehind not implemented in regex m/(?<=\n|\r|\s|^)([a-z0-9._]+)(?=\n|\r|\s|$)/ at ./FHEM/01_FHEMWEB.pm line 1286, <$fh> line 30.
2025.12.10 11:13:38.141 0: Variable length lookbehind not implemented in regex m/(?<=\n|\r|\s|^)([a-z0-9._]+)(?=\n|\r|\s|$)/ at ./FHEM/01_FHEMWEB.pm line 1286, <$fh> line 30.

#2

Sonstige Systeme / Aw: fhempy: tuya (lokal)

Letzter Beitrag von satprofi - 10 Dezember 2025, 11:31:42

Hallo Xsantos,

ich betreibe 3 Tuya-Geräte (2x schaltbare Steckdosen mit Leistungsmessung, 1x Luftentfeuchter) ausschließlich mit lokaler Cloud. Die Geräte hatten genau einmal Zugang zum Internet zur Einrichtung

Viele Grüße Gisbert

wie stellst du das an ? bei mir geht nichts mehr über lokale anbindung. nur mehr mit tuya-connector.

#3

Automatisierung / Aw: Unerklärlicher Zustand im ...

Letzter Beitrag von Marko1976 - 10 Dezember 2025, 11:23:31

Heute Nacht auch wieder:
Gestern Abend manuell auf "ZuHause" gestellt, beim Schlafengehen automatisch auf "Schläft" umgesprungen.
Dann plötzlich um 6:15 Uhr bemerkt, dass die Anzeige wieder auf "Verreist" steht.
Als ich dann entgültig aufgestanden bin stand es auf "ZuHause".

Habe jetzt mal ein Logfile erweitert, dass sowohl die Personen-, als auch den Wohnungszustand, die Anwesenheit beider Handys sowie die Anzeige ob geladenwird oder nicht mitloggt.

Was mir gestern aufgefallen ist, war der Punkt, dass die SubApp Autoremote - die Tasker benötigt um Fhem-Kommandos auf dem Handy auszuführen - deaktiviert war.

Eine Abwesenheitssimulation durch ausschalten des WLan's konnte das Problem nicht reproduzieren. Hatte zuerst den Verdacht, dass es immer nach einer Abwesenheit passiert, doch dem wiederspricht ja auch der Wechsel heute Nacht.

#4

Anfängerfragen / Aw: (wahrscheinlich gelöst) Ba...

Letzter Beitrag von eisman - 10 Dezember 2025, 11:11:37

hi,

nach entfernen der Module Nina und DWD, lief FHEM fehlerfrei,
gestern Vormittag, habe ich DWD wieder aufgenommen und musste
gegen Abend den PC-Namen ändern. Dabei sind einige Netzwerk-Probleme
aufgetreten, darunter auch die Zeit Verschiebung (siehe Bild).

da ich im Zuge des Umbaus auch von HyperV -> ProxMox gewechselt habe,
musste ich einige PC auch umbenennen, zum Zeitpunkt war DWD und Nina
nicht Installiert. hierbei waren keine Auffälligkeiten in den Plots zu sehen!

Code Auswählen Erweitern

defmod DWD DWD_OpenData
attr DWD alertArea 808222000
attr DWD alertLanguage DE
attr DWD alias DWD
attr DWD devStateStyle style="text-align:right;;;;font-weight:bold;;;;color:#FFA400;;;;"
attr DWD event-on-change-reading .*
attr DWD event-on-update-reading a_count
attr DWD forecastDays 7
attr DWD forecastProperties PPPP,FF,VV,FX1,DD,wwd,ww,Tn,Tx,TTT,SunD1,SunD3,R101,RR1c,RR3c,R600,Neff,weekday,date
attr DWD forecastResolution 3
attr DWD forecastStation 10729
attr DWD forecastWW2Text 1
attr DWD group DWD
attr DWD room Wetterstation
attr DWD stateFormat a_time
attr DWD timezone Europa/Berlin

mit der sub WetterTemp() genutzt.

leider schaffe ich es aktuell nicht das Problem mutwillig nachzustellen,
weder durch Internet oder Netzwerk Blockaden. eine Zeile ist mir im log
aufgefallen (1753 von DWD).

nach dem ich gestern DWD wieder entfernt habe, lief das Netzwerk und FHEM wieder
ordnungsgemäß.

ich werde mal weiter versuchen den Fehler auf die spur zu kommen.

gruss

#5

Automatisierung / Aw: KNX Jalousiesteuerung mit ...

Letzter Beitrag von Beta-User - 10 Dezember 2025, 10:40:57

Ohne Doppelpunkt.

@Beta-User: Stimmt das dann trotzdem so, meinst ja?

Nein! Bei getrennten Devices erst den "set", dann das Device, zu trennen mit Doppelpunkt.

#6

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von peterboeckmann - 10 Dezember 2025, 10:35:46

Hallo TheTrumpeter,

Helligkeitssensor

hast Du an jeder PV-Fläche so einen Helligkeitssensor? Unterscheidet die Helligkeit sich je nach Ausrichtung der Module?
Ich könnte mir vorstellen, dass Einstrahlung und Abschattung von der Helligkeit erfasst werden. Aber auch diffuse Strahlung?
Meine Anlage besteht aus einem nach ONO und einem nach WSW ausgerichteten String. Daher meine Fargen.

Und etwas OffTopic: Hast Du einen Helligkeitssensor "von der Stange" oder selbst was gelötet? Wie hast Du den umgesetzt?

Viele Grüße,
Peter

#7

Automatisierung / Aw: KNX Jalousiesteuerung mit ...

Letzter Beitrag von superverbleit - 10 Dezember 2025, 10:34:48

Ich habe das attr ASC_SlatPosCmd_SlatDevice so gewählt:

Code Auswählen Erweitern

ASC_SlatPosCmd_SlatDevice DG.Treppenhaus.Jalousie.Lamelle Pos.Absolute
Ohne Doppelpunkt.

@Beta-User: Stimmt das dann trotzdem so, meinst ja?

Ich habe ja nur das attr ASC_Open_Pos z.B. mit 50:60 gewählt, bzw. ASC_Closed_Pos 100:100

Das der ASC Log gar nichts von den Lamellen meldet, ist ja schon auch komisch, oder?
Auch im Lamellen Device Log sehe ich ja nichts.

#8

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 10 Dezember 2025, 09:17:44

Dessen Werte korrelieren sehr gut mit der (momentanen) PV-Leistung

Ja, das glaube ich dir und das sieht man auch.

Das Problem ist, dass die gemessenen Werte ein Pendant in der Vorhersage brauchen um damit direkt einen Korrekturfaktor ableiten zu können.
Also:

Gemessen Lumen -> Vorhersage in Lumen  -> führt zu einem Korrekturfaktor X bei sonst gleichen! weiteren Bedingungen (Bewölkung etc.).

Gemessen rad1h -> Vorhersage in rad1h  -> führt zu einem Korrekturfaktor X bei sonst gleichen! weiteren Bedingungen (Bewölkung etc.).

Da diese Gegebenheiten (auch rad1h) nicht gemessen, sondern nur vorhergesagt werden, ergibt sich diese Vorgehensweise:

Vorhersage in rad1h X + Vorhersage von Rahmenbedingungen (Bewölkung etc.) -> Vorhersage PV in Wh/h  -> gemessen PV in Wh/h  -> führt zu Korrekturfaktor der bei der nächsten Vorhersage von rad1h X mit gleichen/sehr ähnlichen Rahmenbedingungen angewendet wird.

Umgesetzt / unterstützt durch einen Strahlungs-/Helligkeitssensor würde es sich so darstellen:

Vorhersage in Lumen X + Vorhersage von Rahmenbedingungen (rad1h, Bewölkung etc.) -> Vorhersage PV in Wh/h  -> gemessen PV in Wh/h  -> führt zu Korrekturfaktor der bei der nächsten Vorhersage von Lumen X mit gleichen/sehr ähnlichen Rahmenbedingungen (rad1h, Bewölkung etc.) angewendet wird.

Dadurch ergibt sich die Notwendigkeit eine Vorhersage in Lumen für die kommenden Stunden zu haben, was nicht gegeben ist.

Diesen Zusammnhang gibt es auch bei Verwendung eines neuronalen Netzes. Wenn man die KI mit dem gemessenen Lumen-Wert im Training füttert (was als gemessener Wert sehr sinnvoll ist), benötigt man für die Abfrage des trainierten Modells zur Prognose ebenfalls einen Eingangswert Lumen für die abgefragte Stunde. Der steht aber nicht zur Verfügung, maximal als irgendwie geartete Umrechnung des prognostizierten rad1h falls man das überhaupt umrechnen kann. Dann kann man aber auch gleich rad1h benutzen wie es aktuell getan wird ODER man hat einen Strahlungsmesser der die Solarstrahlung misst und man diese gemessenen Werte beim KI Trainung verwendet. Dann macht es wieder Sinn.

Abgesehen von der ganzen Betrachtung haben die Ungenauigkeite bei der Bewölkungsprognose deutlich mehr Einfluß auf das Ergebnis als andere Faktoren. Eine einzige größere Wolke am sonst wolkenlosen Himmel kann die Stundenprognose zerstören wenn deren Schatten genau auf die kleine Solarfläche von 10 x 10 Meter fällt. Wir sind schon ein wenig vermessen in einem solchen Mikrokosmos Stundenprognosen aufzustellen ... klappt aber irgendwie doch ganz gut über weite Strecken. 

LG,
Heiko

#9

FHEM Development / Aw: Keine commits mehr unter F...

Letzter Beitrag von Otto123 - 10 Dezember 2025, 08:48:34

@Sidey nein brauchst Du nicht. Dein Workflow wird keine nennenswerte Last verursachen.

Gestern 19:00 Uhr und 20:00 gab es noch zwei kurze Lastwellen. Seit dem ist wieder Stille eingekehrt.

#10

FHEM Development / Aw: Keine commits mehr unter F...

Letzter Beitrag von Sidey - 10 Dezember 2025, 08:32:22

Aber ob Du derzeit eine Fehlerfreie Runde drehen kannst, kann ich nicht vorhersagen. Die Belastung ist derzeit nicht von Dauer sondern eher in Impulsen. welche IP initiert das?

Ja, hat dann gestern Abend wieder funktioniert. Es waren ja auch nur 8 commits oder so um den dreh

Die IP Adresse kenne ich leider nicht. Wenn der Workflow startet, dann wird eine Azure VM mit dem Job beauftragt. Die läuft dann maximal 1 Stunde.
Beim nächsten Lauf, wird dann eine andere VM beauftragt, da ich glaube dass die VM nach dem Job zerstört wird.
Wenn es aber weiterhilft, kann ich in den Job eine Abfrage für die Adresse einbauen.

Grüße Sidey