Neueste Beiträge

Seiten 1 ... 8 9 10
#91
Heizungssteuerung/Raumklima / Aw: Vitoconnect - Verbesserte ...
Letzter Beitrag von stefanru - 04 Juni 2026, 16:58:47
Hi Ralph,

wow und danke für die detailierte Analyse.
Das ist toll.
Ja klar dein Fix würde mich sehr interessieren.
Perfekt wäre wenn du es als pull request in mein git repo stellen könntest, dann kann ich direkt diffen und deine Änderung übernehmen.
https://github.com/StefanRu1/FHEM/tree/main/FHEM

Nochmals vielen Dank,
Stefan
#92
Wunschliste / offline Update - update rein m...
Letzter Beitrag von quartz - 04 Juni 2026, 14:37:43
Ich würde gerne mein FHEM offline updaten, also ohne jeglichen Internetzugang.

Einfach ein neues Paket einspielen (vgl. https://debian.fhem.de/) ist ja nicht. Ebenso ist auch ein überschreiben mit dem Abzug des SVN's keine Lösung.

Nach https://fhem.de/commandref.html#update, lädt das Update die Steuerdatei https://fhem.de/fhemupdate/controls_fhem.txt und vergleicht die Informationen mit der Installation bzw. aktualisiert die Dateien dann aus dem Netz.

Mein Wunsch wäre, dass Update so zu erweitern, dass zwei Dateien angegeben werden können:
  • die Steuerdatei, allerdings als lokale Datei (z.B. /tmp/controls_fhem.txt)
  • eine Zip-Datei der Dateien (z.B. über die Download-Option im SVN von FHEM (z.B. /tmp/fhem.zip)

Anschliessend soll das Update wie bisher die Steuerdatei verarbeiten, die benötigten Dateien aber aus der ZIP Datei lesen.

Hilfsweise habe ich auch einmal versucht, in einen Abzug des SVN geänderte Dateien aus dem Betrieb einzuspielen und dann zu switchen. Hat aber nicht funktioniert (Probleme mit Auswertungen / Warnungen aus 92_FileLog.pm).

Wie machen denn das andere offline Nutzer, habe ich eine bestehende Möglichkeit übersehen?
#93
Heizungssteuerung/Raumklima / Aw: Vitoconnect - Verbesserte ...
Letzter Beitrag von rabe - 04 Juni 2026, 14:26:49
Hallo Stefan,
ich habe bei meiner fhem-Installation Probleme mit einem regelmäßigen Freeze, der von Vitoconnect herrührt. Ich nutze die aktuelle Version v1.1.2 (SVN 31188). Mit Freezemon konnte ich die Freezes identifizieren. Der Freeze tritt alle 5 Minuten für 4 Sekunden auf.

Mit Hilfe von Claude Code habe ich ich nun das Modul analysiert und dabei sind zwei Bugs aufgefallen


Bug 1: Falsches Parsing in vitoconnect_getErrorCode (Schrittweite 4 statt 6)

Die Schleife in vitoconnect_getErrorCode liest die *.raw.entries-Readings mit Schrittweite 4 ($i += 4), obwohl jeder Eintrag aus 6 Feldern besteht:

 customer, 1, OwnBus, S.134, status, 2026-06-04T06:40:54.000Z

Durch den falschen Stride werden Fehlercodes als Timestamps und Timestamps als Fehlercodes behandelt. Konkret bedeutet das: die API wird mit Werten wie "1", "OwnBus" oder "2026-06-04T06:40:54.000Z" als errorCode aufgerufen – alle mit 404 als Antwort.
Auch im device.messages.unknown.list-Reading sieht man das Ergebnis:

  S.134 - 1 - Unbekannter Code (1)
  1 - 2026-06-04T06:40:54.000Z - Unbekannter Code (2026-06-04T06:40:54.000Z)

  Fix: Schrittweite auf 6 setzen und die sechs Felder korrekt zuordnen:

  # vorher:
  for (my $i = 0; $i < @values; $i += 4) {
      my $source   = $values[$i];
      my $code     = $values[$i + 1];
      my $category = $values[$i + 2];
      my $ts_raw   = $values[$i + 3];

  # nachher:
  for (my $i = 0; $i + 5 < @values; $i += 6) {
      my $source   = $values[$i];      # z.B. "customer"
      my $count    = $values[$i + 1];  # z.B. "1"
      my $bus      = $values[$i + 2];  # z.B. "OwnBus"
      my $code     = $values[$i + 3];  # z.B. "S.134"
      my $category = $values[$i + 4];  # z.B. "status"
      my $ts_raw   = $values[$i + 5];  # z.B. "2026-06-04T06:40:54.000Z"

  ---

Bug 2: FHEM-Freeze durch HttpUtils_BlockingGet im Non-Blocking-Callback

vitoconnect_getErrorCode wird aus vitoconnect_getResourceCallback aufgerufen – also innerhalb eines Non-Blocking-Callbacks. Darin wird für jeden Eintrag HttpUtils_BlockingGet aufgerufen, was den FHEM-Eventloop komplett blockiert.

Meine Freezemon-Logs zeigen 17 blockierende HTTP-Calls pro Update-Zyklus, je ~300 ms → ca. 5 Sekunden Freeze alle 4-5 Minuten. Alle anderen Module werden in dieser Zeit ebenfalls blockiert.

  [Freezemon] fm: possible freeze starting at 16:47:22, delay is 5.206 possibly caused by:
  cb-vitoconnect_getResourceCallback(viesmann_wp) ...

Fix: Einen modul-globalen Cache verwenden, damit jeder Code nur einmal abgefragt wird. Im Normalbetrieb (nach dem ersten Zyklus) entstehen keine blockierenden Calls mehr:

  # Modul-global (einmalig deklarieren):
  my %vitoconnect_errorcode_cache;

  # In vitoconnect_getErrorCode, statt direktem BlockingGet:
  if (exists $vitoconnect_errorcode_cache{$code}) {
      $text = $vitoconnect_errorcode_cache{$code};  # kein HTTP-Call
  } else {
      $text = vitoconnect_mapCodeText($code);        # erst lokal suchen
      if ($text =~ /^Unbekannter Fehlercode/) {
          # nur wenn lokal unbekannt: einmaliger BlockingGet, dann cachen
          my ($err, $msg) = HttpUtils_BlockingGet($param);
          # ... Ergebnis auswerten ...
          $vitoconnect_errorcode_cache{$code} = $text;
      } else {
          $vitoconnect_errorcode_cache{$code} = $text;
      }
  }

  Zusätzlich empfiehlt sich ein Validierungsfilter vor dem API-Call, damit keine Garbage-Werte (Zahlen, Timestamps, Busnamen) an die API gesendet werden:

  next unless $code =~ /^[FISPA]\./;
  ---

Ich habe eine korrigierte Version der Datei erstellt, die nun den Freeze-Fehler bei mir nicht mehr zeigt. Die kann ich gerne zur Verfügung stellen kann, falls das hilfreich ist. Danke für das tolle Modul und die kontinuierliche Weiterentwicklung!

  Viele Grüße,
  Ralph

 
#94
Solaranlagen / Aw: Modul für Ecoflow-Komponen...
Letzter Beitrag von KölnSolar - 04 Juni 2026, 13:12:09
geht. Bisher nur die Energiemanagement-Funktionen. Welche AC meinst Du, output ? Weitere ?

@Oliver: Neue Erkenntnisse zum smartmeter ?

Grüße Markus
#95
Sprachsteuerung / Aw: echodevice: wait for refre...
Letzter Beitrag von Burny4600 - 04 Juni 2026, 13:11:56
Bei mir ist leider der gleiche Fehler seit zwei Tagen vorhanden.

https://forum.fhem.de/index.php?topic=144857.0

#96
Sprachsteuerung / permanente Wiederholungen echo...
Letzter Beitrag von Burny4600 - 04 Juni 2026, 13:09:17
Mir ist aufgefallen, dass seit zwei Tagen sich folgender Eintrag innerhalb kürzester Zeit sich wiederholt.

LOG
Code Auswählen
2026.06.04 12:50:49.826 3: [Amazon.Account] [echodevice_NPMWaitForCookie] [NPM Login Refresh Thu Jun  4 12:50:49 2026] wait for refreshtoken / refreshtoken unkown!! refreshtoken=null EXIST 935refresh-cookie.js = true
2026.06.04 12:50:49.826 3: [Amazon.Account] [echodevice_NPMWaitForCookie] [NPM Login Refresh Thu Jun  4 12:50:49 2026] wait for refreshtoken / refreshtoken unkown!! refreshtoken=null EXIST 935refresh-cookie.js = true

Ich habe aber keine Änderungen vorgenommen, und das System funktioniert.
Was fehlt jetzt, dass sich die Einträge refreshtoken unkown! sich ständig wiederholt?

Selbes Problem unter https://forum.fhem.de/index.php?topic=144852.0 behandelt.
#97
FHEM Code changes / Revision 31330: Utils.pm: add ...
Letzter Beitrag von System - 04 Juni 2026, 12:51:04
Revision 31330: Utils.pm: add processing for unregister

Utils.pm: add processing for unregister

Source: Revision 31330: Utils.pm: add processing for unregister
#98
FHEM Code changes / Revision 31329: 55_MiniSIP.pm:...
Letzter Beitrag von System - 04 Juni 2026, 11:41:04
Revision 31329: 55_MiniSIP.pm: add attribute addPeerToInput

55_MiniSIP.pm: add attribute addPeerToInput

Source: Revision 31329: 55_MiniSIP.pm: add attribute addPeerToInput
#99
User stellen sich vor / Aw: Hallo aus der Maker-Ecke: ...
Letzter Beitrag von KölnSolar - 04 Juni 2026, 11:30:02
Hallo Mike,

willkommen in FHEM.

Ich mag es zwar nicht, wenn "Dinge" außerhalb von FHEM laufen, aber für Python gibt es das "Universalmodul" https://github.com/fhempy/fhempy/blob/master/README.md .

Vielleicht hilft es Dir ja.

Markus
#100
User stellen sich vor / Hallo aus der Maker-Ecke: Eige...
Letzter Beitrag von stMike - 04 Juni 2026, 10:33:38
Hallo zusammen,
ich bin frisch auf FHEM gestossen und dachte, ich stelle mich und mein Projekt in dieser Runde einfach mal kurz vor.
Ich bin eher der klassische Hardware-Maker, vorgefertigte Klick-Dashboards interessieren mich weniger.
Mir geht es um Code, maximale Kontrolle und die gute alte Unix-Philosophie.

Was ich im Gepäck habe:
Ich habe mir eine eigene Sensor/Aktor-Elektronik aufgebaut. Die Busserver (Slaves) laufen auf Arduino-Basis in C/C++. Gesteuert wird das Ganze von einem Python-Master auf Raspberry Pi. Das Busprotokoll läuft auf einer CLI-Logik: Ich kann über simple Befehle direkt im Busterminal mit jedem Server kommunizieren. Erweitert wird das Backend flexibel aud dem Pi mit Python, Bash und PHP.
Falls hier jemand an den Bibliotheken für Master oder Slave interessiert ist, teile ich den Code natürlich gerne.

Aktueller Stand:
Als ,,Königsdisziplin" steuert das System bei mir aktuell eine zonenbasierte Bewässerungsautomatik, die Daten logge ich über RRDtool, csv und gelegentlich json.

Beim Einlesen in die Smart-Home-Welt wurde mir schnell klar, dass FHEM im Kern eine ähnliche Unix-Philosophie teilt: Textbasiert, modular, stabil und schlank. Da mein System über Terminal-Befehle gefüttert werden kann, funktioniert die Logik im Grunde ähnlich.
Ich stehe bei FHEM noch ganz am Anfang und möchte als Nächstes lernen, wie man hier die Brücke schlägt. Ich freue mich darauf, mich hier einzulesen, von euren Erfahrungen zu lernen und mich mit anderen Hardware-Freaks auszutauschen!

Viele Grüsse: stMike
Seiten 1 ... 8 9 10