Hauptmenü

Neueste Beiträge

#41
FHEM Development / Aw: HttpUtils_NonblockingGet: ...
Letzter Beitrag von rudolfkoenig - 21 Februar 2026, 13:24:34
Wenn man "Content-Type: multipart/form-data" haben will, dann muss der Inhalt auch dazu passen.
FHEM hatte bisher keine explizite Unterstuetzung dafuer, ich habe jetzt eine gebastelt, und in HttpUtils.pm hinzugefuegt.

Anwendung:
  my $h = { url=>"http://localhost:8080/upload",
            callback=>sub($$$){ Log 1,"ERR:$_[1] DATA:".length($_[2]) } };
  for my $f ("picture1.png","picture2.png") {
    my $content = `cat $f`;
    HttpUtils_AddMultipartData($h, $content,
      {"content-disposition"=>"form-data; name=\"file\"; filename=\"$f\"", "content-type"=>"image/png"});
  }
  HttpUtils_NonblockingGet($h);

Ich habe es mit einem node.js Beispielprogramm getestet, damit funktioniert es.
Da die Doku (RFC7578+RFC2046) mAn schwer zu lesen ist, bin nicht sicher, ob es ueberall funktioniert, deswegen bitte um Feedback.
#42
Sonstige Systeme / Aw: SMA EV-Charger
Letzter Beitrag von RPort - 21 Februar 2026, 13:24:23
Hallo,
bei mir ist ein Problem aufgetreten, das wohl früher schon von Dracolein genmeldet wurde:
Ich habe das Reading Leistung_Ladestation protokolliert, weil ich damit den Soc des angeschlossenen Fahrzeuges hochrechnen will.

Fehler:
Sporadisch werden als Werte wie "WPS-aktivieren" ode "Ausführen" angezeigt.

Grund:
Ich habe im Code nachgeschaut:
In der sub SMAEVCharger_handledata wird für ALLE Livedata, die von der Wallbox kommen, die sub SMAEVCharger_getReadableCode aufgerufen, um einen für Menschen lesbaren Wert zu erhalten.
Das macht aber (insb.) für Leistungs - und Energiedaten keinen Sinn.

Ich schlage vor, den Code wie folgt zu ändern:
# Patch Begin
 # ->Delete:
 # my $val = SMAEVCharger_getReadableCode($item->{"values"}->[o]->{"value"});
 # ->Add:
 my $val = ( substr($livedata->{$item->{"channelId"}},0,6) eq "Status" or              #Does the readingname begin with substring "Status" or
             $livedata->{$item->{"channelId"}} eq "Schalterstellung_Drehschalter" )?   #    is "Schalterstellung_Drehschalter" 
           SMAEVCharger_getReadableCode($item->{"values"}->[o]->{"value"}):            #...get human readable codes
           $item->{"values"}->[o]->{"value"};                                          #...otherwise take the value as is - especially the energy and power data
 # Patch end

#43
Anfängerfragen / Aw: Verknüpfung Logfile mit De...
Letzter Beitrag von betateilchen - 21 Februar 2026, 13:22:46
Das geht über autocreate.

Beschreibung zu autocreate findest Du in der commandref oder über "help autocreate" in der FHEM Befehlszeile.
#44
Sonstiges / Aw: EventAggregator: Patch für...
Letzter Beitrag von betateilchen - 21 Februar 2026, 13:21:52
Zitat von: wurmthomas80 am 20 Februar 2026, 14:59:32Patch

Bei Interesse kann ich gerne den Patch zur verfügung stellen.

Hey, Du hast doch Interesse daran und Du möchtest Feedback haben.

Where's the beef?
#45
Anfängerfragen / Verknüpfung Logfile mit Device
Letzter Beitrag von Archimedes - 21 Februar 2026, 13:19:37
Moin auch,
über welchen Weg wird denn das Logfile mit dem Device verknüpft ? Mal als Beispiel: Ich lege ein neues Homematic Device an, dann wird neben dem Device auch automatisch das Logfile erzeugt.
Im Device unten steht dann 'Probably associated with' und darunter dann das Device und ggf. ein SVG Plot.
Kann ich diese Zuordnung irgendwo ändern ? Geht das ggf. über den Namen des Devices ?
Gruß Axel
#46
Sprachsteuerung / characteristic "displayOrder"
Letzter Beitrag von Wolfpunk - 21 Februar 2026, 13:06:10
Das characteristic "displayOrder" (für service "Television" / Sortierreihenfolge der InputSource Identifier) wird im TLV8 Format angegeben. Hat jemand eine Ahnung, wie man das in FHEM/homebridge-fhem mit einem homebridgeMapping hinbasteln könnte?

Hier ein paar Infos zum characteristic:
https://developers.homebridge.io/#/characteristic/DisplayOrder
https://github.com/homebridge/HAP-NodeJS/issues/644
https://github.com/HomeSpan/HomeSpan/blob/master/docs/TVServices.md

Mein Wert, den ich homebridge-fhem geben möchte wäre dann sowas wie z.B.: [1,1,1, 1,1,2, 1,1,3, 1,1,4]
#47
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von Parallix - 21 Februar 2026, 12:43:54
Zitat von: DS_Starter am 14 Februar 2026, 15:45:23@Parallix, @all,

ConsumerXX->mode kann nun auch den Wert 'mustNot' erhalten. Dadurch kann ähnlich wie bei type 'noSchedule' die Planung verhindert werden.

Hier (m)ein erstes Zwischenfazit:
Das neue Feature funktioniert bestimmungsgemäß und perfekt!

Damit wurde in SF eine wichtige Grundlage zur Berücksichtigung von BEVs geschaffen.

Sehr gut ist auch, dass via consForecastLastDays=0 jetzt auch eine reine Vorwärtsplanung durchgeführt werden kann, bei der historische Daten keine Rolle mehr spielen.

Zur Frage, was noch verbessert werden könnte, muss zunächst festgehalten werden, dass Heiko mit SF schon eine sehr hohes Niveau erreicht hat. Wie auch in der Wissenschaft. sollen wir aber aber weiterhin offen für nützliche Erweiterungen und Verbesserungen sein.

Aus meiner Sicht wäre es insb. in Hinblick BEVs hilfreich, wenn SF den Verbrauch ausgewiesener Consumer (hier ein an einer Wallbox hängendes BEV) nicht grundsätzlich nach vorne propagieren würde. Ausgewiesene Consumer sollten also trotz consForecastLastDays > 0 verbrauchstechnisch nur dann in der Zeitleiste in einem in der Zukunft liegenden Zeitraum auftauchen, wenn

  • es sich um "can"-Consumer handelt und
  • eine "kostenfreie" Ladung mittels zu erwartendem PV-Überschuss möglich ist.

oder
  • es sich um "must"-Consumer handelt und
  • eine ggf. "kostenpflichtige" Ladung erforderlich ist, um das BEV bis zu einer Zielzeit in den Zustand "aufgeladen" zu bringen.

Zitat von: DS_Starter am 14 Februar 2026, 21:35:49Hallo EV-Nutzer,
...
Anmerkung: In vielen Fallen ist es nicht möglich, den SOC eines BEVs aus FHEM heraus abzufragen. Was aber praktisch immer festgestellt werden kann ist, ob das BEV auf einen im Fahrzeug eingestellten Ziel-SOC gebracht worden ist. In diesem Fall erfolgt nämlich ein seitens des Consumers (hier BEV) initiiertes Pausieren des Ladevorgangs, welches FHEM via Wallbox signalisiert wird.

Wenigstens ein Datum fehlt noch in Kontext Deiner BEV-Reading-Liste: Ab 2024 installierte Wallboxen müssen die §14a-Forderung "dimmbar" erfüllen. Es sollte also noch ein Reading geben, mit dem die aktuelle oder zu erwartendene Dimmaufforderung des Netzbetreibers abgefragt werden kann. Da sich ein Dimmbefehl bei Verwendung eines EMS sich nicht zwingend auf ein Verbraucher bezieht, muss und sollte das Reading nicht unmittelbar mit einem Verbraucher assoziiert sein!
#48
Wallboxen und E-Fahrzeuge / Aw: Umstellung auf myHyundai-A...
Letzter Beitrag von Tiroler mk - 21 Februar 2026, 11:38:51
Hallo Reinhard, bin über das EV3-Forum hergekommen und begeistert von der Anleitung - mal sehen, wie weit ich komme.
Wenn ich hänge darf ich mich bitte melden?
fG Markus
#49
Home Connect / Aw: HomeConnect V2 released
Letzter Beitrag von locodriver - 21 Februar 2026, 11:24:46
Ok, dann werde ich das mal angehen und dann berichten...

Danke und ein schönes WE.
#50
Codeschnipsel / Aw: Neues Modul: 73_DepartureB...
Letzter Beitrag von locodriver - 21 Februar 2026, 11:19:22
Endlich wieder eine Möglichkeit, Fahrpläne anzuzeigen...

Dankeschön!