Fórum FHEM Forum

Zitat von: Guybrush am 17 September 2026, 12:48:46 ich schau mir das mal an. das wäre dann aber optional als attribut umzusetzen. Nope: wenn es die Funktion gibt (und setList den Befehl nicht enthält), wird immer deine Zwischenfunktion aufgerufen, wenn diese vorhandenen ist, also das Modul auch geladen. Dann kannst du intern prüfen, ob das ein gültiger set-command (ggf. für den "Channel") ist, oder nicht. Wenn nein: Argumente durchreichen, das ist schon alles. Zum Testen: mal in $cmdList zusätzlichen was reinschreiben, dann weiterreichen und schauen, was du in fhemweb an Kommando auswählen kannst...

ja ist er. ich schau mir das mal an. das wäre dann aber optional als attribut umzusetzen. mit setExtensions hab ich selbst jedenfalls noch nicht so viel gemacht.

Hallo Heiko, lieben Dank für Deine ultraschnelle Reaktion und Deine freundlichen Infos! Zitat von: DS_Starter am 17 September 2026, 08:59:40 EDIT2 : Es geht tatsächlich nur um eine Änderung der Flußlogik für den Fall der Netzladung des Akkus. Ich brauche keine weiteren Infos zur Zeit. Ich denke das kann ich ohne zusätzliche Schlüssel und Einstellung seitens des Users lösen. Ja, nur ein Anzeigeproblem für den Fall wie du ihn genannt hast. Ich werde Deine Korrektur einspielen und beobachten. Und ja, es ist eher selten, dass die Batterie aus dem "Hausnetz" geladen wird, kommt aber regelmäßig bei Initialisierungsläufen der Akkusteuerung (BMS) vor. ChatGPT und ich bedanken sich einstweilen herzlich bei Dir LG, al

Revision 31656: 76_SolarForecast: contrib Version 2.10.3 76_SolarForecast: contrib Version 2.10.3 Source: Revision 31656: 76_SolarForecast: contrib Version 2.10.3

Verkaufe eine Steckkarte für die Steuerung 2107. Habe die Karte jahrelang benutzt, um meine Heizung komfortabel mit FHEM zu steuern und alle relevanten Parameter auszulesen. Muss jetzt aber bedauerlicherweise raus, da ich auf Wärmepumpe umsteige. Die Karte kommuniziert über einen seriellen Anschluss, ein USB Adapter ist dabei, ebenfalls ein Temperatursensor zur Messung der Abgastemperatur (wird an die Karte angeschlossen). In der FHEM Command Refeferenz gibts alles weitere zum KM271. Auf Wunsch kann ich einen Auszug aus meiner fhem.cfg zur Inspiration oder zum Testen bereitstellen. Ich bitte um Preisvorschläge!

Hallo Rudolf, bzgl. readingsgroup habe ich ein eigenes topic eröffnet: https://forum.fhem.de/index.php?topic=145464.0 ======== - ich habe für alle readingsGroup-Devices das attr disabled 1 gesetzt -> im longpoll erscheinen sie (erwartungsgemäß) nicht mehr - was mich allerdings nach wie vor irritiert: ??!! Die ersten 4 bis 5 Einträge im longpoll betreffen Devices, die nicht zu den allowed-Devices gehören ??!! Danach tauchen diese Devices aber nicht mehr auf, d.h. der Rest der Ausgabe entspricht der Erwartung. Woran kann das liegen? Sind anfangs noch Puffer gefüllt?

@al (& all), in meinem contrib liegt ein Update bzgl. der Korrektur Flowcontrol: * Korrektur der Darstellung bei Netzladung der Batterie über den Hausknoten. Ein negativer Energiefluss zwischen Inverterknoten und Hausknoten wird nun korrekt als direkter Fluss Hausknoten → Batterie dargestellt. Der angezeigte Hausverbrauch bleibt davon unberührt. Man braucht keine zusätzlichen Einstellungen/Schlüssel etc. Einfach Einspielen, restarten und testen ob bei Netzladung die Flußrichtung stimmt (und natürlich alles andere wie bisher). LG, Heiko

siehe hierzu auch https://forum.fhem.de/index.php?topic=145450.msg1369072#msg1369072 --- - Für ein FHEMWEB-Device werden in einem zugehörigen allowed-Device in dem attr allowedDevices zulässige Devices aufgezählt. Die readingGroup-Devices gehören nicht dazu. - Trotzdem werden die Werte dieser Devices im longpoll an fremde Anwendungen übermittelt. (Test mit https:// : /fhem?XHR=1&inform=type=status;addglobal=1;filter=.*;since=null;fmt=JSON - Das attr disabled wird für alle readingGroup-Devices auf 1 gesetzt -> Die Einträge im longpoll verschwinden (erwartungsgemäß) => Das Modul readingsGroup scheint den Allowed-Mechanismus nicht umzusetzen => Die Datensicherheit ist verletzt

Zitat von: Prof. Dr. Peter Henning am 17 September 2026, 08:59:09 Alles nett. Aber bei den ganzen Templates fehlt mir vor allem eines: Eine Dokumentation. Warum etwas so gelöst worden ist, was man tun kann, um es zu ändern etc. Puh... Also: Im Quellcode (klar: nicht optimal, aber im Wiki zu attrTemplate sollte es stehen...) steht fast immer (über dem betreffenden template) die (Foren-) Quelle drin, aus der man häufig auch die "immer gleichen" Diskussionen um gute Reading-Namen, den Nachrichtenkreislauf usw. nachvollziehen kann. Weil es mir irgendwann leid war, diese "immer gleiche" Diskussion zu führen, ist meine erste Reaktion auf die Anfrage für ein neues Gadget, man möge doch bitte zuerst den Weg gehen, wie er sich aus "Schritt für Schritt" ergibt, da ist in den Grundzügen erklärt, wie die Attribute aufeinander aufbauen. Die Transferleistung, das dann im eigenen Sinne anzuwenden, werde ich keinem abnehmen. Falls du also Verbesserungsbedarf (v.a.) an der (zusammenfassenden) Doku siehst - feel free. Teils finden sich in desc, teils in den betreffenden Foren dann auch Hinweise, wenn ich Dinge für nicht gut gelöst hielt, die betreffenden User aber nicht willens oder in der Lage waren, die notwendigen Infos beizubringen oder unbedingt an ihrer "Lösung" festgehalten haben. Zitat von: Prof. Dr. Peter Henning am 17 September 2026, 08:59:09 ebusd-Interface eingebaut habe: Massig MQTT-Templates - aber keinerlei Erklärung. Gerade das ist ein Beispiel für jemand, der bei der Mitarbeit

ich hab das in er semantic map in grundzügen drin. Mach doch mal konkrete Vorschläge wie das definiert sein könnte.

Die Info ist für mich eigentlich nicht relevant. Deshalb schaue ich maximal in die Renault App und dort passt es, mein Scenic steht zu Hause.

Ich bekomme noch ein paar Meldungen: Code Auswählen Erweitern 2026.09.16 22:55:39 1: PERL WARNING: Use of uninitialized value $inv_BAT_UDC in string ne at ./FHEM/76_SMAInverter.pm line 1428. 2026.09.16 22:55:39 1: PERL WARNING: Use of uninitialized value $inv_BAT_IDC in string ne at ./FHEM/76_SMAInverter.pm line 1428. 2026.09.16 22:55:39 1: PERL WARNING: Use of uninitialized value $inv_BAT_IDC in multiplication (*) at ./FHEM/76_SMAInverter.pm line 1428. 2026.09.16 22:55:39 1: PERL WARNING: Use of uninitialized value $inv_BAT_UDC in multiplication (*) at ./FHEM/76_SMAInverter.pm line 1428. 2026.09.16 22:55:39 1: PERL WARNING: Use of uninitialized value $inv_BAT_UDC in concatenation (.) or string at ./FHEM/76_SMAInverter.pm line 1471. 2026.09.16 22:55:39 1: PERL WARNING: Use of uninitialized value $inv_BAT_IDC in concatenation (.) or string at ./FHEM/76_SMAInverter.pm line 1472. [/quote] auch bei mir hat es über die Nacht in der Entladephase des Speichers unentwegt solche Nachrichten gehagelt. [code]2026.09.17 00:00:07 1: PERL WARNING: Use of uninitialized value $inv_BAT_UDC in string ne at ./FHEM/76_SMAInverter.pm line 1428. 2026.09.17 00:00:07 1: PERL WARNING: Use of uninitialized value $inv_BAT_IDC in string ne at ./FHEM/76_SMAInverter.pm line 1428. 2026.09.17 00:00:07 1: PERL WARNING: Use of uninitialized value $inv_BAT_IDC in multiplication (*) at ./FHEM/76_SMAInverter.pm line 1428. 2026.09.17 00:00:07 1: PERL WARNING: Use of uninitialized value $inv_BAT_UDC in multiplicat