Neueste Beiträge

#11

Heizungssteuerung/Raumklima / Aw: THZ Tecalor (LWZ Stiebel E...

Letzter Beitrag von willybauss - 04 Juni 2026, 19:05:03

Habe jetzt doch mal im Manual der 504 nachgeschaut. Außer dem Schaltbild hinten gibt's auch noch was im Textteil Kap. 5.9.4 "Anschluss X4". Aber auch da steht nicht viel.

Außerdem gibt's noch die Einstellungen im Kap. 7.4, sh. Anhang. Die hast Du beachtet?

Ansonsten: wie lange ist denn die Anlage schon in Betrieb? Womöglich bist du noch in der Gewährleistungsfrist. Dann ist der Haushersteller oder der Installateur in der Verantwortung. Schließlich hast Du eine WP mit Kühlfunktion gekauft, dann muss die auch funktionieren. In diesem Fall ist es evtl. schädlich, selbst rumzuexperimentieren. Wenn dabei was in die Hose geht ist der, der in der Verantwortung steht, fein raus.

#12

Server - Linux / Aw: ubuntu 26.04. Jeelink USB ...

Letzter Beitrag von Wernieman - 04 Juni 2026, 18:37:04

Ich weiß auch nicht weiter ..

Was mir aber Grundsätzlich auffällt:
Du definiert den Stick direkt:

Code Auswählen Erweitern

define myJeeLink JeeLink /dev/ttyUSB0@57600Zeigst Uns aber zusätzlich den by-id. Warum machst Du es nicht über "by-id"? oder hattest Du nur fürs Debuggen umgestellt?

P.S. Stichwörter:
Powermanagment? Eventuell USB das Stromsparen abgewöhnen.

#13

Wallboxen und E-Fahrzeuge / Aw: Integration von CarConnect...

Letzter Beitrag von Prof. Dr. Peter Henning - 04 Juni 2026, 18:21:46

Der neue CarConnectivity Konnektor vw_eu_data_act müht sich redlich. Dennoch ist die Erfolgsquote beim Datenabruf bescheiden. So ist das in keiner Weise brauchbar.

Im Moment liegt die Schuld ganz klar bei Volkswagen - denn das Portal liefert erneut keine Daten mehr.

Offenbar hat der "Fix" nicht funktioniert.

Ich kann nur empfehlen, tatsächlich die 5 Minuten zu opfern und das Beschwerdeformular der Bundesnetzagentur auszufüllen.

LG

pah

#14

Wallboxen und E-Fahrzeuge / Aw: Integration von CarConnect...

Letzter Beitrag von klaus.schauer - 04 Juni 2026, 18:14:16

https://github.com/mikrohard/CarConnectivity-connector-vw-eu-data-act

Dann soll das Portal angeblich alle 15 Minuten Daten bereitstellen-allerdings nur für die Fahrzeuge, bei denen man "Hauptnutzer" ist.
Angeblich, sage ich: Für ein Fahrzeug gibt es immerhin jetzt 5 LEERE Zip-Dateien, für das zweite Fahrzeug noch gar nichts. Sieht so aus, als ob die auch noch Schwierigkeiten haben...

Dann habe ich natürlich versucht, den CarConnectivity-connector-vw-eu-data-act zu installieren.
Edit: Das klappte jetzt auch, das Ding versucht Daten von dem Portal zu holen.


Allerdings ist das VW EU Data Act Portal seit dem 30.5. tot - es liefert absolut keine Daten mehr.

Jetzt sind die Dateien - wenn sie nach einiger Zeit nach der Anmeldung angezeigt werden - tatsächlich mit Daten gefüllt. Leider werden die Daten aber nicht oder nur mit massiver Verzögerung aktualisiert.

Der neue CarConnectivity Konnektor vw_eu_data_act müht sich redlich. Dennoch ist die Erfolgsquote beim Datenabruf bescheiden. So ist das in keiner Weise brauchbar.

#15

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

#16

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?

#17

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

 

#18

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

#19

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

[LOG]

#20

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 Erweitern

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.