- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#1
Unterstützende Dienste / Aw: Neues Modul: Signalbot (In...
Letzter Beitrag von FilliFairy - 28 Februar 2026, 12:26:57Hallo,
nach dem letzten Update auf 0.13.22 startet der signal.service nicht mehr. Hier die Fehlermeldungen und die Ergebnisse der Hinweise zur Fehlerbehebung aus dem Wiki:
Mir ist klar, dass ich mit buster eine relativ alte Version verwende. Einen Hinweis, dass signal-cli mit buster nicht mehr läuft habe ich bisher nicht entdeckt.
Kennt jemand das Fehlerbild oder hat ggf. Hinweise wo ich noch suchen könnte?
Hat jemand signal-cli 0.13.22 unter buster am Laufen?
Vielen Dank für Eure Mühe Euch mit dem Fall zu beschäftigen!
Gruß
Gerhard
nach dem letzten Update auf 0.13.22 startet der signal.service nicht mehr. Hier die Fehlermeldungen und die Ergebnisse der Hinweise zur Fehlerbehebung aus dem Wiki:
Code Auswählen
signal.service - Send secure messages to Signal clients
Loaded: loaded (/etc/systemd/system/signal.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2026-02-28 11:39:20 CET; 4min 37s ago
Process: 9951 ExecStartPre=/bin/sleep 10 (code=exited, status=0/SUCCESS)
Process: 10174 ExecStart=/opt/signal/bin/signal-cli --config /var/lib/signal-cli daemon --system (code=exited, stat
Main PID: 10174 (code=exited, status=1/FAILURE)
Feb 28 11:39:06 Raspi06 systemd[1]: Starting Send secure messages to Signal clients...
Feb 28 11:39:20 Raspi06 signal-cli[10174]: WARN Manager - Failed to call libsignal-client: /tmp/libsignal82849004091
Feb 28 11:39:20 Raspi06 signal-cli[10174]: Missing required native library dependency: libsignal-client
sudo ldconfig -v | grep libsignal_jni.so
ldconfig: Pfad »/lib/arm-linux-gnueabihf« mehrfach angegeben
ldconfig: Pfad »/usr/lib/arm-linux-gnueabihf« mehrfach angegeben
ldconfig: /lib/arm-linux-gnueabihf/ld-2.28.so is the dynamic linker, ignoring
ldconfig: /lib/ld-linux.so.3 is the dynamic linker, ignoring
find / -name libsignal-client-*.jar 2>/dev/null
/opt/signal/lib/libsignal-client-0.86.1.jar
cat /tmp/signal_install.log
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
Mir ist klar, dass ich mit buster eine relativ alte Version verwende. Einen Hinweis, dass signal-cli mit buster nicht mehr läuft habe ich bisher nicht entdeckt.
Kennt jemand das Fehlerbild oder hat ggf. Hinweise wo ich noch suchen könnte?
Hat jemand signal-cli 0.13.22 unter buster am Laufen?
Vielen Dank für Eure Mühe Euch mit dem Fall zu beschäftigen!
Gruß
Gerhard
#2
FRITZ!Box / Aw: AVM SmartMeter und Monatsw...
Letzter Beitrag von RalfRog - 28 Februar 2026, 12:15:59Die Zeitintervalle braucht man nicht setzen.
Anfang bis Ende ist durch die Begriffe Stunde, Tag, Monat, Jahr definiert.
Mit dem Attribut delta readings (bzw. auch durationReadings, minAvgMaxReadings) definiert man (weitere) vom Modul zu berechnende Readings die im Default des Moduls nicht enthalten sind (wie z. B. energy, power, temperature etc) .
Anfang bis Ende ist durch die Begriffe Stunde, Tag, Monat, Jahr definiert.
Mit dem Attribut delta readings (bzw. auch durationReadings, minAvgMaxReadings) definiert man (weitere) vom Modul zu berechnende Readings die im Default des Moduls nicht enthalten sind (wie z. B. energy, power, temperature etc) .
#3
Solaranlagen / Aw: APSystems EZ-1
Letzter Beitrag von Ralf9 - 28 Februar 2026, 11:24:53An dem $ liegts nicht, es funktioniert auch bei einem kürzerem wlan Passwort mit $-=
Ich habe inzwischen herausgefunden, daß es bei der Fritzbox keine Möglichkeit gibt, von lokalen Subnetz auf das Gast Subnetz zuzugreifen.
Mir ist aufgefallen, daß bei der Firmware 1.9.0 ein PV Eingang nur max ca 415W kann. Es gibt Aussagen, daß bei älterer Firmware auch max 500W geht.
Ich habe 2 Aiko 490W an Eingang 1 und 1 Aiko 490W an Eingang 2.
Evtl fällt dies nur auf, wenn man 3 Module angeschlossen hat.
Ich habe inzwischen herausgefunden, daß es bei der Fritzbox keine Möglichkeit gibt, von lokalen Subnetz auf das Gast Subnetz zuzugreifen.
Mir ist aufgefallen, daß bei der Firmware 1.9.0 ein PV Eingang nur max ca 415W kann. Es gibt Aussagen, daß bei älterer Firmware auch max 500W geht.
Ich habe 2 Aiko 490W an Eingang 1 und 1 Aiko 490W an Eingang 2.
Evtl fällt dies nur auf, wenn man 3 Module angeschlossen hat.
#4
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 28 Februar 2026, 10:27:57@Parallix,
Für eine Betrachtung der Wahrscheinlichkeit eines (zukünftigen) Energieverbauchs durch die KI Prognose ist dieser Wert von grundlgender Bedeutung, es ist ein Kernsignal für "Ladebedarf".
Sollte dieser Wert nicht geliefert werden können muß man einfach festhalten, dass ein Consumer vom Typ "BEV" nicht sinnvoll angelegt werden kann sofern man damit die Prognose-KI füttern möchte. D.h. die Auswahl eines entsprechend Profils wäre nur möglich wenn diese Voraussetzung vorliegt. Allerdings würde ich aus Gründen der programmtechnischen Vereinfachung den SoC Wert der Bat bei einem BEV-Typ verpflichtend definieren. Sonst nimmt man einfach "other" in solchen Fällen.
ZitatAnmerkung: 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.So wie ich bisher gelesen habe, ist es in den dargestellten Fällen kein Problem den SoC des BEV auszulesen.
Für eine Betrachtung der Wahrscheinlichkeit eines (zukünftigen) Energieverbauchs durch die KI Prognose ist dieser Wert von grundlgender Bedeutung, es ist ein Kernsignal für "Ladebedarf".
Sollte dieser Wert nicht geliefert werden können muß man einfach festhalten, dass ein Consumer vom Typ "BEV" nicht sinnvoll angelegt werden kann sofern man damit die Prognose-KI füttern möchte. D.h. die Auswahl eines entsprechend Profils wäre nur möglich wenn diese Voraussetzung vorliegt. Allerdings würde ich aus Gründen der programmtechnischen Vereinfachung den SoC Wert der Bat bei einem BEV-Typ verpflichtend definieren. Sonst nimmt man einfach "other" in solchen Fällen.
#5
FHEM Development / Aw: X_FW_detailFn($$$$) - Wie ...
Letzter Beitrag von rudolfkoenig - 28 Februar 2026, 10:21:33ZitatMit anderen Worten: Ein klitzekleines bisschen über das Ziel herausgeschossen.Naechster Vorschlag:
- FW_detailFn definieren und FW_deviceOverview setzen
- FW_detailFn liefert je nach ShowDetails Attribut den Inhalt oder undef zurueck.
Nebeneffekt: damit wird in der Detailansicht bei allen Instanzen von DepartureBnT immer erst die standard Anzeige angezeigt, und danach (wenn ShowDetails gesetzt) die modulspezifische Anzeige.
Der Benutzer kann das zwar mit dem deviceOverview FHEMWEB(!) Attribut uebersteuern, das gilt aber fuer alles, was ueber diese FHEMWEB-Instanz angezeigt wird.
#6
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 28 Februar 2026, 10:13:22Hallo cs-online,
umgestellt werden.
LG,
Heiko
Zitatwie kann es senn sein, dass hier eine Abweichung von -136 % ausgerechnet wird ? Der Tooltip sagt, mehr produziert als vorhergesagt, wieso ist der Wert dann negativ ?Das ist eine Frage der Perspektive. Es wurde weniger vorhergesagt als tatsächlich produziert, also negativ (nach unten) verschätzt. Das ist eine Ansichtssache und kann mit
Code Auswählen
plantControl->genPVdeviation=...:reverse umgestellt werden.
ZitatUnd noch eine Frage: Was ist denn die CO-Abweichung ?Das ist die Abweichung der Verbrauchsprognose, also der Prognose des Energieverbrauchs im Haushalt.
LG,
Heiko
#7
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von cs-online - 28 Februar 2026, 10:05:47Hallo zusammen,
wie kann es senn sein, dass hier eine Abweichung von -136 % ausgerechnet wird ? Der Tooltip sagt, mehr produziert als vorhergesagt, wieso ist der Wert dann negativ ? Meist passt das ja so inetwa, d.h. die generelle Funktion ist schon da, aber manchmal bekomme ich solche etwas merkwürdigen Angaben. Und noch eine Frage: Was ist denn die CO-Abweichung ?
Grüße
Christian
wie kann es senn sein, dass hier eine Abweichung von -136 % ausgerechnet wird ? Der Tooltip sagt, mehr produziert als vorhergesagt, wieso ist der Wert dann negativ ? Meist passt das ja so inetwa, d.h. die generelle Funktion ist schon da, aber manchmal bekomme ich solche etwas merkwürdigen Angaben. Und noch eine Frage: Was ist denn die CO-Abweichung ?
Grüße
Christian
#8
Automatisierung / Aw: DbRep mit komplexem MySQL ...
Letzter Beitrag von DS_Starter - 28 Februar 2026, 09:39:47Hallo Christian,
im Modul (Perl) selbst wird kein SQL-Syntxcheck durchgeführt. Die Meldung (DBD::mysql::st...) wird direkt vom Datenbanktreiber (DBD Perl-Modul) zurückgeliefert.
Möglicherweise wäre es zielführend im CPAN zu forschen (Version des DBD) bzw. DBD::MariaDB umzustellen.
Die eingesetzten Versionen siehst du im Configcheck des zugeordneten DbLog-Devices.
Grüße,
Heiko
im Modul (Perl) selbst wird kein SQL-Syntxcheck durchgeführt. Die Meldung (DBD::mysql::st...) wird direkt vom Datenbanktreiber (DBD Perl-Modul) zurückgeliefert.
Möglicherweise wäre es zielführend im CPAN zu forschen (Version des DBD) bzw. DBD::MariaDB umzustellen.
Die eingesetzten Versionen siehst du im Configcheck des zugeordneten DbLog-Devices.
Grüße,
Heiko
#9
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 28 Februar 2026, 09:28:22Morgen zusammen,
bin wieder zurück und lese mich langsam wieder ein.
Die wichtigste und erfreulichste Nachricht für mich ... der Schnee ist weg und die Sonne lacht.
@All-Ex,
Es gibt also eine Disharmonie in den API's die berücksichtigt werden müssten. Darüber hinaus müsste die herrkömmliche Vorhersage ohne KI drastisch erweitert werden um ähnlich der Bewölkung von Sonnenstand und Schneebelag abhängige Korrekturfaktortabellen erstellt und verarbeitet werden. Ein Blick in "get ... pvCircular" lässt erahnen welcher Aufwand dahinter steckt. In diesen Korrekturen müsste auch die Zellenneigung mit der empirischen "Abrutschkorrektur" und Leistungsminderung durch Schneehöhe auf den Zellen berücksichtigt werden.
Alles in Allem ist das zuviel Aufwand.
Allerdings, 300P hat es auch bereits erwähnt, habe ich vor auch die Solarprognose auf die AI::FANN KI umbubauen. Damit ergäbe sich m.M. nach durchaus die Möglichkeit die Schnee-Daten mit einfließen zu lassen sofern man eine liefernde API ausgewählt hat. Bei den anderen API's werden diese Daten dann schlichtweg als "0" vorgegeben.
@Parallix,
@MartinD,
diese Problematik wurde vielleicht mal mit einer contrib-Version "eingeschleppt". Ich kann es nicht sagen, denn die Schlüssel werden stringent erstellt. Dennoch wird in der kommenden Version ein einfaches Ausfrufen von "get ... pvHistory" solche ungültigen Tages- und Stundenschlüssel automatisch entfernen.
LG,
Heiko
bin wieder zurück und lese mich langsam wieder ein.
Die wichtigste und erfreulichste Nachricht für mich ... der Schnee ist weg und die Sonne lacht.
@All-Ex,
Zitataktuell liegt Schnee auf meinen Solarzellen, daher gibt es 0 Watt Leistung. Wie wäre es, wenn die Vorhersage Schnee berücksichtigt?Wie 300P bereits erwähnte, hatten wir dieses Thema bereits öfter. Eine Problematik ist, dass die OpenMeteo diese Schneewerte liefert (kenne ich), aber das DWD-Device in FHEM dies hingegen nicht ermölicht. Es liest MOSMIX S/L aus, der OpenData Server liefert Schneewerte aber über MOSMIX-SNOW aus was nicht eingebunden ist. Die API Forecast.Solar liefert diese Werte nach einem ersten Check ebenfalls nicht.
Es gibt also eine Disharmonie in den API's die berücksichtigt werden müssten. Darüber hinaus müsste die herrkömmliche Vorhersage ohne KI drastisch erweitert werden um ähnlich der Bewölkung von Sonnenstand und Schneebelag abhängige Korrekturfaktortabellen erstellt und verarbeitet werden. Ein Blick in "get ... pvCircular" lässt erahnen welcher Aufwand dahinter steckt. In diesen Korrekturen müsste auch die Zellenneigung mit der empirischen "Abrutschkorrektur" und Leistungsminderung durch Schneehöhe auf den Zellen berücksichtigt werden.
Alles in Allem ist das zuviel Aufwand.
Allerdings, 300P hat es auch bereits erwähnt, habe ich vor auch die Solarprognose auf die AI::FANN KI umbubauen. Damit ergäbe sich m.M. nach durchaus die Möglichkeit die Schnee-Daten mit einfließen zu lassen sofern man eine liefernde API ausgewählt hat. Bei den anderen API's werden diese Daten dann schlichtweg als "0" vorgegeben.
@Parallix,
ZitatDas neue Feature funktioniert bestimmungsgemäß und perfekt!Das freut mich. Deine weiteren Anmerkungen/Vorschläge muß ich mir erst noch genauer anschauen und bewerten.
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.
@MartinD,
diese Problematik wurde vielleicht mal mit einer contrib-Version "eingeschleppt". Ich kann es nicht sagen, denn die Schlüssel werden stringent erstellt. Dennoch wird in der kommenden Version ein einfaches Ausfrufen von "get ... pvHistory" solche ungültigen Tages- und Stundenschlüssel automatisch entfernen.
LG,
Heiko
#10
Anfängerfragen / Aw: Energiekostenmeßgerät VOlt...
Letzter Beitrag von Guybrush - 28 Februar 2026, 09:14:23z.b. der Nous A1T läuft mit tasmota und liefert nach Kalibrierung Messwerte mit 1% Genauigkeit. Das ist schon sehr gut und genauer wird mans vermutlich auch nicht kriegen. Selbst unkalibriert kannst du damit Verbräuche von 1-2 Watt messen. Tasmota Geräte lassen sich wunderbar über mqtt in fhem steuern und kosten sogar weniger als das Voltcraft Gerät. Das schöne an den Tasmota Geräten ist auch, dass du die so konfigurieren kannst, dass Änderungen beim Stromverbrauch direkt über mqtt an fhem gesendet werden und man so in Sekundenbruchteilen davon erfährt.