Hauptmenü

Neueste Beiträge

Seiten 1 ... 7 8 9 10
#81
FRITZ!Box / Aw: FritzSmart ab Modul-Versio...
Letzter Beitrag von JoWiemann - 20 September 2026, 19:36:14
Hallo kabanett,

da bin ich jetzt irritiert. Ich habe in der Version 26.09.15 noch zwei Kleinigkeiten gefunden, die aber nicht direkt das Verhalten bei Dir erklären würden. Trotzdem, spielt doch bitte die angehängte Version einmal ein. Bitte zwingend Fhem neu starten.
Was ich schon mal hatte, war ein ähnliches Verhalten, das sich nur durch einen Neustart des Server auf dem Fhem läuft beheben lies. Hier war es allerdings so, dass einige Fhem Devices ein komisches Verhalten gezeigt haben.

Grüße Jörg
#82
Anfängerfragen / Aw: PERL WARNING: Argument "" ...
Letzter Beitrag von Adimarantis - 20 September 2026, 19:29:30
Danke für den Hinweis.
Da ich mir nicht sicher bin, mit welchem Wert das zu initialisieren ist, hab ich das jetzt eher an der Fehlerzeile gelöst:
Code Auswählen
sub elapsed($$) {
  my ($self, $t)= @_;
  return defined($self->{autoreset}) && $self->{autoreset} ne '' && defined($self->{_t0}) && ($t - $self->{_t0} >= $self->{autoreset});
}
Langsam wird die Liste an Modulen die ich vom Autoupdate ausschliessen muss immer länger. Teilweise hatte ich da versucht Kontakt mit den Autoren aufzunehmem, aber ohne Rückmeldung. Ich spiele mit dem Gedanken meine inzwischen über Monate bis Jahre bewährten Änderungen einfach einzuchecken

Jörg
#83
Sonstiges / Aw: MQTT best current practice
Letzter Beitrag von TomLee - 20 September 2026, 18:49:50
ZitatAls Absicherung in `fhem.pl` würde ein `next if(!$modules{$m}{ParseFn});` in der Dispatch-Schleife genügen, unabhängig davon, wer den Eintrag erzeugt hat.

Könntest du dich bitte damit noch beschäftigen und dazu deine Meinung teilen?





#84
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von Hadl - 20 September 2026, 18:38:16
Hallo,
ich nutze die Batteriesteuerung mit OTP schon länger, aber seit ca. 2 Wochen klappt das nichtmehr.
Jeweils zum Ende einer Stunde bekomme ich "target likely achievable? no" und einen sehr geringen "Ratio of remaining surplus", und dadurch eine hohe Ladeleistung.
Zum Beginn der neuen Stunde ist dann wieder Überschuss vorhanden und die Ladeleistung wird wieder beschränkt.
Code Auswählen
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ######################### Start Battery Management DebugLog #########################
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> setup values: lowSoc=5 %, upSoc=20 %, maxSoc=100 %, stepSoc=5 %, careCycle=25
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> pvHistory values: yesterday=19, batymaxsoc=94.9 %, batysetsoc=100 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> current values: SoC=83.3 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> Battery share factor of total required load: 1.00
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> today -> PV fc: 53900 Wh, con till sunset: 24 Wh, Surp: 53876 Wh
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> tomorrow -> PV fc: 64569 Wh, con till sunset: 2096 Wh, Surp: 62997 Wh (75% con)
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> selected energy for charging (the higher positive Surp value from above): 62997 Wh
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - basics -> expected energy for charging after application Share factor: 62997 Wh
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step1 Bat 01 - compare with SoC history -> preliminary new Target: 100 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step2 Bat 01 - basics -> Energy expected for charging: 62997 Wh, need until maxsoc: 1283 Wh
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step2 Bat 01 - calc care SoC -> docare: 1, care SoC: 100 %, remain days until care SoC: 0, Target: 100 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step3 Bat 01 - basics -> max SOC so that predicted PV can be stored: -720 %, newtarget: -720 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step3 Bat 01 - charging probability -> docare: 1, Target: 100 % (no change)
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step4 Bat 01 - basics -> docare: 1, lowSoc: 5 %, upSoc: 20 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step4 Bat 01 - observe low/up limits -> Target: 100 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step5 Bat 01 - rounding the SoC to steps of 5 % -> Target: 100 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> SoC Step6 Bat 01 - force charging request: yes (battery charge is below minimum SoC)
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt - Inverter 'Fronius_Symo1' cap: 10000 W, Power limit: 100 % -> Pmax eff: 10000 W
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt - Inverter 'Fronius_Symo2' cap: 12000 W, Power limit: 100 % -> Pmax eff: 12000 W
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt - Summary Power limit of all Inverter (except feed 'grid'): 22000 W
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt - The limit for grid feed-in is: 18800 W
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - selected charging strategy: smartPower
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - general load termination condition: 0
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - control time Slot - Slot start: 00:00, Slot end: 23:59
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - control barrier SoC: 50 % / 3840 Wh
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - control barrier Parameter: set:4444
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - Battery efficiency used: 87 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - weighted self-consumption: 0 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - Target load and target time: 100 % / 7680 Wh / -
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - Percentage of the total amount of charging energy required: 100.0 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeMgmt Bat 01 - The PV generation, consumption and surplus listed below are based on the battery's share of the total amount of charging energy required!
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - used safety margin: 20 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - charging target: 7680 Wh, E requirement incl. efficiency: 1475 Wh -> target likely achievable? no
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - Ratio of remaining surplus 130 Wh / energy requirement to achieve the load target: 8.82 %
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 20/10 - hod:11/00, lr/lc:1/1, SocS/E:6397/7680 Wh, SurpH/D:7794/130 Wh, OTP:3000/149 W
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 20/11 - hod:12/01, lr/lc:0/1, SocS/E:7680/7680 Wh, SurpH/D:0/0 Wh, OTP:0/- W
2026.09.20 10:59:52 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 20/12 - hod:13/02, lr/lc:0/1, SocS/E:7680/7680 Wh, SurpH/D:0/0 Wh, OTP:0/- W

...

2026.09.20 11:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - used safety margin: 20 %
2026.09.20 11:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - charging target: 7680 Wh, E requirement incl. efficiency: 1475 Wh -> target likely achievable? yes
2026.09.20 11:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 - Ratio of remaining surplus 8933 Wh / energy requirement to achieve the load target: 605.75 %
2026.09.20 11:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 20/11 - hod:12/00, lr/lc:1/1, SocS/E:6397/7680 Wh, SurpH/D:8933/8933 Wh, OTP:1768/1473 W
2026.09.20 11:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 20/12 - hod:13/01, lr/lc:0/1, SocS/E:7680/7680 Wh, SurpH/D:0/0 Wh, OTP:0/- W
2026.09.20 11:00:04 1: PV_SolarForecast DEBUG> ChargeOTP Bat 01 20/13 - hod:14/02, lr/lc:0/1, SocS/E:7680/7680 Wh, SurpH/D:0/0 Wh, OTP:0/- WDu darfst diesen Dateianhang nicht ansehen.
Die Ladeleistung OTP wird daher zum Ende der Stunde immer ans Maximum gezogen und es wird "not Acchievable" angezeigt.
Heute war für PV sogar ein sehr guter Tag, es war reichlich Überschuss vorhanden.

An der SF Config habe ich seit einiger Zeit nichtsmehr geändert, woran könnte das liegen?
Auffällig ist das "SurpH/D" für alle Stunden außer der aktuellen immer 0 ist und "con till sunset" sehr gering ist.


Vielen Dank

Hadl
#85
FHEM Code changes / Revision 31668: 14_SD_RSL.pm: ...
Letzter Beitrag von System - 20 September 2026, 18:11:04
Revision 31668: 14_SD_RSL.pm: precompile Match regex, use code references for module ...

14_SD_RSL.pm: precompile Match regex, use code references for module functions, add FHEM::Meta support

Source: Revision 31668: 14_SD_RSL.pm: precompile Match regex, use code references for module ...
#86
Anfängerfragen / Aw: Mähroboter Navimow Integra...
Letzter Beitrag von FrankL - 20 September 2026, 17:39:04
Hallo,

falls ihr Interesse an einer nativen Integration eurer Navimow-Modelle in FHEM habt, könnt ihr gerne das 58_Navimow.pm-Modul testen.

MfG Frank
#87
Sonstige Systeme / Modul 58_Navimow.pm zur Integr...
Letzter Beitrag von FrankL - 20 September 2026, 17:18:19
Hallo liebe Freunde des gepflegten Rasens,

ich möchte an dieser Stelle das von mir geschriebene Modul 58_Navimow.pm vorstellen. Es dient der Einbindung von Navimow-Geräten (Mährobotern), die per Cloud über die Navimow-App erreichbar sind.

Seit ein paar Monaten hat Navimow hierzu ein offizielles SDK (siehe https://github.com/segwaynavimow/navimow-sdk) sowie eine Integeratation für Home Assistant (https://github.com/segwaynavimow/NavimowHA) in Phyton veröffentlicht. Da es noch kein Navimow-Modul für FHEM in Perl gibt, habe ich mal meine Erfahrungen aus dem DaikinCloud-Modul genutzt und ein passenden Navimow-Modul geschrieben.

Das Navimow-Modul habe ich unter https://github.com/frank-lie/Navimow veröffentlicht und halte es dort auf dem neusten Stand.

Was kann das Modul?
1. Das Modul ist in der Lage, den Autorisierungsprozess zu starten, um die erforderlichen Token zu bekommen bzw. automatisch zu erneuern.
2. Es können per HTTP-Request Daten des Gerätes wie Status (isRunning, isPaused, isDocking, isLifted, etc) und Batteriestand abgefragt werden.
3. Es kann per MQTT Livedaten zum Standort (x,y relativ zur Dockingstation), zum Mähfortschritt, zur gemähten Fläche, etc empfangen.
4. Es können "einfache" Steuerbefehle (start,stop,pause,resume,dock) gesendet werden. Weitere Möglichkeiten zum Steuern gibt die API aktuell nicht her bzw. sind nicht dokumentiert.

Was kann man damit sinnvolles machen?
Wie bei vielen Geräten im Smarthome steht natürlich die Überwachung der Geräte im Vordergrund und der Wunsch auf Optimierung bzw. Anpassung auf die individuellen Situationen. Zum Beispiel: Wenn der Mähroboter aktiv ist, soll sichergestellt sein, dass nicht die Rasenbewässerung angeht. Oder der Mäher soll die Restfläche zu Ende mähen, wenn der Ladezustand der Batterie hierfür wieder ausreichend ist und nicht erst wieder auf 100% aufladen. Oder es soll ein Alarm in FHEM ausgelöst werden, wenn der Mäher einen bestimmten Bereich erreicht oder verlässt. Die Ideen der Automatisierung sind da vielfältig.

Welche Geräte sind damit kompatibel?
Das Modul wurde erfolgreich mit einem Navimow i205 AWD getestet ;-). Da das Konzept jedoch allgemeingültig gehalten ist, können Daten von allen Navimow-Modellen, die in der Navimow-App registriert sind, ausgelesen werden. Da die Steuerkommandos in der API auf die oben genannten fünf Befehle beschränkt sind, sollte es auch hier keine Probleme mit der Kompatibilität geben. Ich freue mich aber über entsprechendes Feedback von euch mit Angabe des konkreten Modells, so dass ich eine Positiv-Liste anlegen kann. Das Modul unterstützt auch mehere Modelle im gleichen Account. Allerdings bin ich da auf Feedback angewiesen, da ich nur ein einzelnes Gerät im Einsatz habe.

Wie funktioniert das ganze?

1. Damit das Modul in FHEM verwendet werden kann, ist der folgende update-Befehl in FHEM auszuführen:
Code Auswählen
update all https://raw.githubusercontent.com/frank-lie/Navimow/main/controls_Navimow.txtUm automatisch immer die aktuelle Version des Moduls im Rahmen des FHEM-Befehls update zu erhalten, kann man den Link auch generell als Update-Quelle hinzufügen:
Code Auswählen
update add https://raw.githubusercontent.com/frank-lie/Navimow/main/controls_Navimow.txt
2. Nach einem Update von FHEM sollte in der Regel ein Neustart von FHEM gemacht werden, damit alle Änderungen ordnungsgemäß geladen werden:
Code Auswählen
shutdown restart
3. Für die Kommunikation mit der Navimow-Cloud ist in FHEM zunächst ein Master-Device anzulegen:
Code Auswählen
define <NAME> Navimow
4. Sobald das Master-Device erstellt worden ist, kann der AUTHORIZATION_LINK (zu finden als INTERNAL im Master-Device) aufgerufen werden, um den Autorisierungsprozess zu starten. Ihr werdet auf die Seite von Navimow geleitet (diese Seite wurde zwar vorrangig für Home Assistant gestaltet, aber das soll uns nicht weiter stören), müsst euch dort einloggen und das Captcha lösen und werdet im Anschluss auf die REDIRECT_URI weitergeleitet. Bei Aufruf der "Standard-REDIRECT_URI" wird euer Browser sagen, dass die Verbindung fehlgeschlagen ist. Das ist nicht schlimm, denn ihr benötigt nur den Link der Internetseite aus dem Browser mit dem Autorisierungscode. Kopiert also den vollständigen Link "http://localhost/callback?code=xxxxx" in die Zwischenablage.

5. Gebt in FHEM den Autorisierungscode als set-command ein:
Code Auswählen
set <NAME> AuthCode <kompletter Link der Rückgabe-URL>
6. Mit dem Setzen des Autorisierungscodes bekommt FHEM die erforderlichen Token für den Zugriff auf die Navimow-Cloud übermittelt. Die Einrichtung des Master-Devices ist damit abgeschlossen. Die Mower-Devices werden standardmäßig beim Abruf der Daten aus der Cloud automatisch als Device in FHEM angelegt. Im Anschluss wird automatisch eine MQTT-Verbindung zum Navimow-Server hergestellt, damit die Real-Time-Daten per MQTT empfangen werden können.

Hinweis: Die Real-Time-Daten per MQTT werden im "Sekundentakt" gepublisht, wenn das Gerät aktiv ist bzw. sich bewegt. Wenn der Mähroboter in der Dockingstation steht, kommen relativ selten Real-Time-Daten per MQTT rein.

Wer Schritt 4 bis 6 automatisieren bzw. perfektieren will, kann auch eine individuelle REDIRECT_URI konfigurieren. Nähere Hinweis dazu gibt es auf Github. Da diese Schritte nur einmalig durchgeführt werden müssen und die Konfiguration einer individuellen REDIRECT_URI sehr fehleranfällig sein kann, empfehle ich jedem Einsteiger einfach die Schritte 1 bis 6 durchzuführen und den Autorisierungscode manuell aus der Browserzeile in die Zwischenablage zu kopieren und manuell an FHEM zu übergeben, auch wenn das etwas umständlich anmutet.

Warum habe ich das Modul nicht eher veröffentlicht?
Die ursprünglichen Versionen des Moduls waren zwar funktionsfähig, aber sehr rudimentär und hatten zunächst nur HTTP-Requests unterstützt. Der Nutzen des Ganzen hielt sich damit stark in Grenzen. In das Thema MQTT musste ich mich zunächst einarbeiten. Nun ist es soweit, dass auch der MQTT-Support enthalten ist und ich meine innnere Beta-Phase erfolgreich abgeschlossen habe.

Auch wenn sich die Mähsaison langsam dem Ende nähert, hat vielleicht der ein oder andere Interesse an diesen Modul.

MfG Frank
#88
Bastelecke / Aw: ESP RGBWW Controller - Fir...
Letzter Beitrag von vbs - 20 September 2026, 17:16:42
Super Trick mit dem Speichern in der RTC  8)
#89
FRITZ!Box / Aw: FritzSmart mit Fritz Labor...
Letzter Beitrag von LuckyDay - 20 September 2026, 16:53:19
Zitat von: RappaSan am 20 September 2026, 16:31:13ritzbox 7490 mit FRITZ!OS: 8.40?
Wo gibts die Version denn?
Offiziell finde ich nur die FRITZ!OS 7.62.

der kollege  roelleke hat eine 7590 laut log
#90
FRITZ!Box / Aw: FritzSmart mit Fritz Labor...
Letzter Beitrag von RappaSan - 20 September 2026, 16:31:13
ritzbox 7490 mit FRITZ!OS: 8.40?
Wo gibts die Version denn?
Offiziell finde ich nur die FRITZ!OS 7.62.
Seiten 1 ... 7 8 9 10