Hauptmenü

Neueste Beiträge

#1
DOIF / Aw: ring2(): Font-Farbe des Te...
Letzter Beitrag von Damian - 05 April 2026, 21:30:29
Das Attribut heißt fill:white

Auf der Seite https://wiki.fhem.de/wiki/DOIF/uiTable_Schnelleinstieg findest du diverse Beispiele, wenn du nach fill sucht.

Es gibt übrigens den Parameter $lightness, der dir die Farbe verschiedener SVG-Elemente des Ringes aufhellen kann, dazu findest du auch Beispiele auf der obigen Wiki-Seite.
#2
MQTT / Aw: CarConnectivity
Letzter Beitrag von trupf - 05 April 2026, 21:12:39
Damit zusammen mit carconnectivity autocreate in fhem funktioniert muss der Parameter "clientid" in der Datei carconnectivity.json gesetzt werden, in dem Bereich wo das mqtt-Plugin definiert wurde, also z.B. so
"plugins": [
            {
                "type": "mqtt", // Definition for the MQTT Connection
                "config": {
                    "broker": "localhost",
                    "port": 1883,
                    "clientid":"CarConnect",
                    "locale":"de_DE.UTF-8",
                    "netrc": "/etc/weconnect_id3" // path to netrc file oder alternativ username und password hier ergänznen
                }
            }
        ]

Carconnect funktioniert soweit eigentlich gut, aber ich brauche noch eine sinnvolle readingList Definition um sinnvolle Readingsnamen zu bekommen, die auch nicht durch andere MQTT-Topics doppelt benutzt werden....
#3
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von klaus.schauer - 05 April 2026, 20:56:36
Zitat von: DS_Starter am 05 April 2026, 14:08:06So sollte es sein, sofern dein Consumer type=bev nicht aktiviert ist solange das EV nicht erkannt wurde via evid. Du siehst es auch am Reading z.B.:
consumer20  name='BEV 2' state='deactivated' mode='mustNot' planningstate='noSchedule'

Das ist genau das Architekturmerkmal. Erst wenn der EV via evid erkannt ist, wird der so definierte ConsumerXX aktiv und liefert die zugeordneten Daten.
Hat man mehr als einen EV im Haushalt, legt man mehr als einen bev-Consumer an und achtet darauf evid entsprechend unterschiedlich zu definieren.
Ersetzt der Consumer-Typ bev den Consumer-Typ charger oder sind bei Bedarf x Consumer von Typ charger und y Consumer vom Typ bev zu definieren?
#4
Sprachsteuerung / Aw: (WIP) FHEMWEB interaktiv (...
Letzter Beitrag von schwatter - 05 April 2026, 20:49:19
Zitat von: Beta-User am 04 April 2026, 11:48:18
Zitat von: schwatter am 04 April 2026, 10:00:35Lebt ihm hier und jetzt, bzw abonniert nur Devices bei Raum- oder Deviceübersicht.
Das ist in der Tat ein Problem.

Zitat von: schwatter am 04 April 2026, 10:00:35Wenn doch, vielleicht hat wer ein Beispiel?
Hmm, ich _glaube_, du hattest ein passendes Beispiel geliefert!!!

Meine Mikro-Aktivierung
Zitat von: Beta-User am 03 April 2026, 11:24:46        my $js = "if((document.querySelector('input[name=\"fw_id\"]')||{}).value==='$hash->{FW_ID}'){f18_stt()}";
        FW_directNotify("#FHEMWEB:$_", $js, "")
            for devspec2array("TYPE=FHEMWEB");
basiert auf deinem notify-Code, jetzt zu finden unter https://wiki.fhem.de/wiki/FHEMWEB/VoiceControl:_Web-STT_%26_Hardware-Wakeword#Beispiel:_notify, dort der Abschnitt #Hilfe.
Damit machst du was genau? Du sendest an eine mehr oder weniger unbekannte Stelle formatierten Text hin, um den in genau einem FHEMWEB-Client anzuzeigen... Das müßte doch eigentlich genauso für TTS-Infos gehen ;) , oder stehe ich auf dem Schlauch?



Hey, ne. Da reden wir aneinander vorbei. Mir ging es darum, im Webinterface direkt per inform Updates zu Devices
zu bekommen, welche nicht in einem Raum/DeviceOverview sind. Per FW_directNotify wird ja nur ein JS-Befehl abgeschickt.

Gruß schwatter
#5
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von Parallix - 05 April 2026, 20:48:46
Nach einem Osterbesuch wieder zu Hause angekommen, liegt mir folgenden Log-Eintrag vor:
...
2026.04.05 15:20:10 1: SF - Open-Meteo API server response:  SSL connect attempt failed error:0A000126:SSL routines::unexpected eof while reading
2026.04.05 15:28:59 1: reload: Error:Modul 99_mySolarForecastUtils deactivated:
2026.04.05 15:28:59 1: Including fhem.cfg
...
Da mein Watchdog-Prozess ausgelöst hat, frage ich mich, ob die Kontaktaufnahme zu o.g. Server möglicherweise blockierend ist. Wenn ja, so wäre das der Grund für das Ansprechen des Watchdog-Prozesses und den daraus resultierenden FHEM-Neustart.
#6
Bastelecke / Aw: ESP RGBWW Controller - Fir...
Letzter Beitrag von pjakobs - 05 April 2026, 20:46:33
so, der OTA bug ist behoben und insgesamt habe ich ein paar Funktionen eingebaut, um den OTA Prozess noch sicherer zu machen (so rebootet ein Controller etwa automatisch, wenn er zwei Minuten im OTA festhängt - das sollte genügen, um selbst auf vergleichsweise langsamen Verbindungen das 1MB Binary runterzuladen)

Was ist neu: Wenn Ihr die System Settings Seite auf einem PC aufruft, werden jetzt die Informationen und die anderen Punkte nebeneinander dargestellt. Das schafft etwas mehr Überblick. Auf kleinen Bildschirmen bleibt alles wie gehabt.

Neu ist der Log Viewer, der erstmal keine Funktion hat, wenn Ihr nicht den Log Companion laufen habt. Log Companion ist ein kleiner Container, den Ihr auf einem beliebigen Linux Rechner (etwa Eurer fhem Instanz - auf Fritzboxen wird es eher nicht gehen) mitlaufen lassen könnt. er ist nötig, weil ein javascript frontend wie das Lightinator WebUI nicht selbst einen udp Port aufmachen kann. Der Companion ist ein udb rSyslog listener, der die Logs für alle Controller mitschreibt.
Darauf zugreifen könnt Ihr auf zwei Weisen: einmal über das Controller Frontend selbst - der Logviewer hier zeigt Euch das Log des aktuellen Controllers (Achtung: nur die debug builds schreiben logs, die anderen habe die Funktion zwar im Grunde, aber sie schreiben keine logs)
Alternativ könnt Ihr direkt auf das UI des Log Companions zugreifen, das ist unter <host-auf-dem-der-container-läuft>:4821 erreichbar und bietet zwei Ansichten:
- einmal eine Übersicht über alle Controller, die im Netz bekannt sind. Dort könnt Ihr entweder zentral für alle oder gezielt für einzelne die log funktion ein und ausschalten.
- oben rechts ist ein settigs Button, über den Ihr ein paar grundlegende Einstellungen vornehmen könnt (obwohl das meiste automatisch entdeckt werden kann) und - ich weiß nicht für wie viele das interessant ist - die Logs auch an eine Loki Instanz weiterleiten könnt. Loki ist die Logdatenbank des Grafana Projektes und wird in großen Netzen meist zum zentralen Logging genutzt. So habt Ihr dann etwa über ein Grafana Frontend die Möglichkeit, die Logs aller Eurer Controller einzusehen.
- links ist die Liste der verfügbaren Controller, wenn Ihr dort auf einen klickt, dann wird der rechte Bereich des Fensters zum Log Fenster des gewählten controllers, sprich Ihr seht dort live, was Ihr sonst auf der seriellen Konsole sehen würdet - weitestgehend jedenfalls, denn wenn der Controller nicht mit dem Netz verbunden ist, kann er natürlich auch nichts senden.
- es gibt ein paar Änderungen, die hoffentlich dafür sorgen, dass Ihr mir in Zukunft trotzdem Crash Dumps schicken könnt. Ich speichere jetzt 56 Stack Worte und die Register bei einem Crash im RAM der Echtzeituhr, der wird bei einem Reboot nicht gelöscht und ist auch bei einem Crash relativ sicher zu beschreiben - wenn dort ein Crash hinterlegt ist, wird der nach einem neustart auf den Logserver geschrieben. Wenn alles funktioniert kann der sogar sofort eine Analyse vornehmen, das ist aber, mangels Crash, bisher nicht getestet.
Was gab's sonst noch.
Ich habe die Speichernutzung ein bisschen optimiert. Das Frontend hat sich manchmal drauf verlassen, dass der Controller auch große Datenstrukturen schon streamen kann - kann er nicht immer, dann hat er mit einem HTTPERR 429 geantwortet und der Client hat zunehmend länger gewartet, bis er erneut versucht hat, auf den Controller zu schreiben.
Jetzt zerlegt das Frontend von Vornherein große Strukturen und schreibt sie in kleineren Paketen. Wenn dabei ein 429 auftritt, verzögert es.
Im Info block (den gibt es jetzt in zwei Versionen, einmal unter "/info" in der alten Version für fhem, einmal unter "/info?v=2" in einer strukturierten Variante für moderne Clients) lieft der Controller jetzt auch den niedrigsten HEAP in den letzten 10 Minuten und seit Neustart sowie die Anzahl der Situationen, in denen er eine Anfrage abgelehnt hat, weil nicht genug RAM zur Verfügung stand. Wenn ich meine Implementation richtig gemacht habe, sollte der 10 Minuten Fehler Counter nie mehr als eins oder zwei sein.

ansonsten ist viel hinter den Kulissen passiert und es passiert noch mehr, etwa arbeite ich gerade an einem komplett neuen Szeneneditor. Der kommt dann später.
#7
Unterstützende Dienste / Aw: Modul IPCAM überarbeitet
Letzter Beitrag von heikoh81 - 05 April 2026, 20:27:44
Hallo,
ich habe es so gelöst, weil immer mehr Kameras nur noch rtsp können und kein mjpg mehr, und auch ich eine jahrzehntealte Installation mit ipcam, Verknüpfung zu Bewegungsmeldern etc. habe.
  • go2rtc als docker-image (muss nicht auf dem historischen Raspberry laufen)
  • go2rtc kann Standbilder von rtsp erzeugen, kostet fast keine Rechenleistung und auch keinen Datenverkehr, so lange kein Standbild angefordert wird
  • IPCAM greift auf eine bestimmte Adresse, die dir go2rtc anzeigt, zu, und holt so beliebig viele Standbilder ab

Viele Grüße,
Heiko
#8
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von grappa24 - 05 April 2026, 19:48:35
Zitat von: DS_Starter am 05 April 2026, 14:08:06Das ist genau das Architekturmerkmal. Erst wenn der EV via evid erkannt ist, wird der so definierte ConsumerXX aktiv und liefert die zugeordneten Daten.
Hat man mehr als einen EV im Haushalt, legt man mehr als einen bev-Consumer an und achtet darauf evid entsprechend unterschiedlich zu definieren.
Damit steht nun auch mein bev-Consumer:
MQTT2_evcc type=bev power=3500 pcurr=chargePower:W etotal=etotal:kWh icon=car evid=evid:Cupra exconfc=1 batCap=10400 currSoC=currSoC targetSoC=80und weil meine Fronius Wallbox absolut nix zur Identifikation des BEV via MQTT beiträgt und ich eh immer nur ein- und dasselbs BEV lade hab ich ein Reading evid in meinem Wallbox-Device fest mit dem Wert Cupra belegt - kann man mal machen  ;)
#9
FHEM Code changes / Revision 31082: SIGNALduino: a...
Letzter Beitrag von System - 05 April 2026, 19:30:10
Revision 31082: SIGNALduino: align SD_Protocols helper filename and location with ...

SIGNALduino: align SD_Protocols helper filename and location with package name

Source: Revision 31082: SIGNALduino: align SD_Protocols helper filename and location with ...
#10
FHEMWEB / Aw: [Voicecontrol] Button für ...
Letzter Beitrag von schwatter - 05 April 2026, 19:28:59
Nabend Rudolf,

ich habe mich mal genauer mit FHEMWEB.pm und fhemweb.js beschäftig. Mir ist es gelungen, ein Device in einem
Raum per inform mit hinzuzufügen ohne das das Device vorhanden ist.

1. Änderungen in fhemweb.js
A) Ganz oben in der Datei (bei den anderen Variablen):
var FW_additionalInformIds = [];

B) Innerhalb der function FW_longpoll():
// Suche die Zeile mit 'var since = "null";' und ändere den Block darunter so ab:

  var since = "null";
  if(FW_serverGenerated)
    since = FW_serverLastMsg + (FW_serverGenerated-FW_serverFirstMsg);

  // --- START PATCH ---
  var informString = "type=status;filter="+filter+";since="+since+";fmt=JSON";

  // IDs aus dem globalen Array hinzufügen, falls vorhanden
  if(typeof FW_additionalInformIds !== "undefined" && FW_additionalInformIds.length > 0) {
      informString += ";addIds=" + FW_additionalInformIds.join(",");
  }

  var inform = encodeURIComponent(informString);
  // --- END PATCH ---

  var query = "?XHR=1"+
              "&inform="+inform+
// ... Rest der Funktion bleibt gleich

2. Änderungen in 01_FHEMWEB.pm
Suche die sub FW_initInform($$).

Perl
# --- In 01_FHEMWEB.pm ---
# Suche die Zeile: my %h = map { $_ => 1 } devspec2array($filter);
# Füge direkt danach diesen Block ein:

  my %h = map { $_ => 1 } devspec2array($filter);

  # --- START PATCH ---
  if($me->{inform} && $me->{inform}{addIds}) {
    foreach my $d (split(",", $me->{inform}{addIds})) {
      if($defs{$d}) {
        $h{$d} = 1;
        $FW_visibleDeviceHash{$d} = 1;
      }
    }
  }
  # --- END PATCH ---

  $h{global} = 1 if( $me->{inform}{addglobal} );
// ... Rest der Funktion bleibt gleich

Danach kann ich in der Browserkonsole den Inform auslösen:
window.FW_additionalInformIds = ["Pumpe_FBH_Pwr"];
FW_closeConn(); setTimeout(FW_longpoll, 500);


Danach kam mir aber die Idee, das das nicht so dolle ist. Jedesmal stoppen um dann wieder zu starten.
Wie wäre es, wenn direkt in FHEMWEB-Device ein attr additionalInformID hinzugefügt wird. Da kann dann
eine Liste mit Device(s) eingetragen werden, welche in jedem Raum verfügbar sein soll.

Gruß schwatter {"frohe": "Ostern"}