Hauptmenü

Neueste Beiträge

#1
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 15 März 2026, 14:22:03
@Dieter,

die generellen Anlagenparameter müssen natürlich stimmen, aber da gehe ich davon aus.
OpenMeteo ist eigentlich eine feine Sache, insbesondere OpenMeteoDWD_D2-API läuft bei mir auch sehr gut.
#2
Derzeit funktioniert keine Autorisierung mehr über https://my.home-assistant.io/auth

Hat jemand erfolgreich eine eigene, lokale Autorisierung in FHEM hinbekommen, vorzugsweise ohne Öffnung der Firewall?

LG

pah
#3
Solaranlagen / Aw: Modul PylonTech
Letzter Beitrag von DS_Starter - 15 März 2026, 14:18:17
Ich hatte bisher 8 US3000C Batterien, also Adresse 1-8 im DEF des Moduls.
Jetzt kam eine weitere US3000C hinzu, d.h. Adresse 9. Die Adressierung hat nicht mehr funktioniert.
Möglicherweise hängt der Erfolg von der FW des Masters ab. Bei mir ist es die 2.4

Grüße,
Heiko
#4
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von dieter114 - 15 März 2026, 14:17:14
Zitat von: DS_Starter am 15 März 2026, 11:48:03OpenMeteo bringt uns die direkte globale Stahlung als Antwort, zu sehen über "get ... radiationApiData" was dann 'nur' noch umgerechnet wird auf die Anlagenparamter.
stimmt: das passt sich tagsüber an.
Nur wenn in der Vorhersage absolute "Mondwerte" stehen hilft es nicht.
Ich versuche einmal einen anderen Anbieter.
Danke für die schnelle Antwort.
LG WDS
#5
FRITZ!Box / Aw: 72_FRITZBOX.pm wird zu 72_...
Letzter Beitrag von elektron-bbs - 15 März 2026, 14:13:03
Hallo Jörg,
ich habe jetzt auch die neue Version 72_FritzSmart.pm installiert.

Was ist in der Hilfe damit gemeint - Schaltsteckdose?
set <name> smartHome <deviceID> <switch:0|1>
schaltet den Steckdosenadapter aus|an
Ich habe versucht, mit diesem Befehl meine Schaltsteckdose FRITZ!Smart Energy 200 zu schalten. Da bekomme ich aber folgende Fehlermeldung:
set FritzBox_7590 smartHome 17 1
ERROR: first parameter: 17 not a valid reference for a SmartHome THERMOSTAT
2026.03.15 13:27:22 3: [FritzBox_7590 | 7590 | 154.08.21 | Set_Modul.2142] - BASIC:set FritzBox_7590 smartHome - 17 1
2026.03.15 13:27:22 2: [FritzBox_7590 | 7590 | 154.08.21 | Helper_retMsg.2113] - SIGNIFICANT:location: 2487 | Msg: ERROR: first parameter: 17 not a valid reference for a SmartHome THERMOSTAT
Laut "get FritzBox_7590 luaInfo smartHomeDevices" ist das Gerät mit folgenden Werten registriert:
ID        17
Category  SOCKET
Model     FRITZ!Smart Energy 200

Bei dem Versuch mit "get FritzBox_7590 luaInfo smartHomeDevices" ist FHEM allerdings mit folgenden Fehlermeldungen im Log abgeschmiert:
2026.03.15 13:29:44 3: [FritzBox_7590 | 7590 | 154.08.21 | Get_SmartHome_Devices_List.13482] - BASIC:Fritz_SmartHome_Device_List (Fritz!OS: 08.21)
Undefined subroutine &Fritz::FileRead called at ./FHEM/72_FritzSmart.pm line 14611.
Ich musste die Zeile ändern in:
     my ($err, @l) = main::FileRead($smh_pre_path);
Mit dieser Änderung hat der Befehl dann funktioniert. FileRead kommt im Modul 5 mal vor.
#6
Homematic / Aw: HM-SEC-SCO nach Exclude ne...
Letzter Beitrag von Otto123 - 15 März 2026, 13:50:07
das klingt gut, danach sollte er zurückgesetzt sein.

Du kannst an dem Sensor eigentlich nicht viel konfigurieren, d.h. man kann den auch ohne Pairing gut betreiben. Er meldet ja.
Ansonsten zeig mal ein komplettes list von einem Sensor.
#7
Solaranlagen / Aw: Modul PylonTech
Letzter Beitrag von satprofi - 15 März 2026, 13:48:10
hallo.
was meinst du mit "ab 9 " funktioniert es nicht? habe selbst 11 units, und alles klappt.
#8
Solaranlagen / Aw: Störungen bei SolarEdge
Letzter Beitrag von satprofi - 15 März 2026, 13:45:37
alles bestens
#10
Sonstiges / Mein FHEM "hängt" sich bei ins...
Letzter Beitrag von hasselh - 15 März 2026, 13:25:24
Hallo @rudolfkoenig,

ich monitore die Antwortzeit meiner FHEM Instanz über den Telnet Port. Diese liegt normalerweis unter 5 Millisekunden. Ein Watchdog startet die Instanz dann automatisch neu, wenn die Instanz für 60 Sekunden nicht antwortet. Und ich beobachte schon seit Jahren, dass diese Neustarts immer genau dann passieren, wenn auch mein Internet Aussetzer hat. Also wollte ich dem mal auf den Grund gehen...

Die Kommunikation ins Internet ist bei mir in FHEM wie folgt definiert:
attr global proxy 192.169.0.100:8118
attr global proxyExclude 127.0.0.1|192.168.*|192.169.*
attr global blockingCallMax 128

Den ausgehenden Port testweise zu blockieren hat bei mir nicht geholfen das Verhalten zu reproduzieren. Aber die ausgehende Kommunikation testweise gaanz langsam zu machen schon. Dazu führe ich den folgenden Code auf dem Rechner aus, auf dem auch FHEM läuft:
tc qdisc del dev eth0 root 2>/dev/null
tc qdisc add dev eth0 root handle 1: htb default 99
tc class add dev eth0 parent 1: classid 1:1 htb rate 20bps ceil 20bps burst 20 cburst 20
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \
  match ip dst 192.169.0.100/32 \
  match ip dport 8118 0xffff \
  flowid 1:1

Was jetzt passiert, ist, dass nach einiger Zeit - speziell, wenn mein TelegramBot pollt oder wenn ich eine Nachricht über Telegram verschicke - quasi jegliche (auch lokale !) Kommunikation von FHEM anfängt "einzufrieren". Das betrifft bei mir telnet, mqtt, FHEMWEB und noch weitere Module. Da es zumindest in einem meiner Tests auch vorkam, dass FHEM auch mit deaktivierten TelegramBot einfriert, scheint es m.E. eher ein allgemeines Problem zu sein und nicht ausschließlich an dem TelegramBot zu liegen.

Hierzu ein paar Fragen:
- ist die Anzahl der parallel laufenden NonBlockingGet Aufrufe in FHEM irgendwie limitiert ?
- gibt es irgendeine Konfiguration, mit der ich das Verhalten von FHEM hierzu beeinflussen kann ?
- kann ich irgendwie die Anzahl der aktuell gleichzeitig laufenden "Kommunikations Threads" in FHEM herausfinden ?

Danke im Voraus, Hayo