- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#11
Automatisierung / Aw: notify Status während disa...
Letzter Beitrag von Guybrush - 11 März 2026, 16:21:55ich glaub das was du willst geht vom Modul her nicht. das wird meine ich nur intern berücksichtigt.
Du könntest aber zb im notify ein reading 'temporaryDisabled' (oder anders benannt) im notify_test device auf true oder 1 setzen. Dann noch ein at device mit +30 sek anlegen, was das reading wieder auf false oder 0 setzt. ob man das wirklich braucht bezweifel ich, da man 30 sekunden ja auch schnell am timestamp ablesen kann und das ja eigentlich nur fürs konfiguieren wenn überhaupt nötig ist?
Du könntest aber zb im notify ein reading 'temporaryDisabled' (oder anders benannt) im notify_test device auf true oder 1 setzen. Dann noch ein at device mit +30 sek anlegen, was das reading wieder auf false oder 0 setzt. ob man das wirklich braucht bezweifel ich, da man 30 sekunden ja auch schnell am timestamp ablesen kann und das ja eigentlich nur fürs konfiguieren wenn überhaupt nötig ist?
#12
MQTT / Aw: [gelöst] MQTT Ansatz für P...
Letzter Beitrag von Remstäler - 11 März 2026, 16:17:36Also ich benutze für die Abfrage vom Raspy den gleichen Benutzer wie mit der Anker-Handy-App und das klappt problemlos.
Das wurde von Anker in einem Update im Herbst ja auch extra so angepasst.
Ich hab einen Intervall von 60 Sekunden eingestellt. Nach 30 Tagen läuft dann evtl. der Token ab, den muss man dann erneuern. Läuft nun seit 2-3 Monaten fehlerfrei.
Das wurde von Anker in einem Update im Herbst ja auch extra so angepasst.
Ich hab einen Intervall von 60 Sekunden eingestellt. Nach 30 Tagen läuft dann evtl. der Token ab, den muss man dann erneuern. Läuft nun seit 2-3 Monaten fehlerfrei.
#13
Automatisierung / Aw: notify Status während disa...
Letzter Beitrag von betateilchen - 11 März 2026, 16:12:32Zitat von: yersinia am 11 März 2026, 15:47:45gibt es auch einen eleganteren Weg zu erkennen, ob
- das notify Device gerade (temporär) disabled ist nach einem trigger (disabledAfterTrigger) aber nach Ablauf der Zeit (hier 30s) wieder aktiv lauscht?
- das notify Device gerade (temporär) disabled ist wegen (disabledForIntervals)?
- das notify Device nicht getriggert hat, weil es keinen passenden Event gegeben hat?
- nein
- nein
- nein
Das notify wird IMMER getriggered und ausgeführt. Es prüft erst bei der Ausführung für sich selbst, ob es aufgrund irgendwelcher Attribute (oder set active/inactive) disabled ist oder nicht.
Sollte es zu der Erkenntnis kommen, dass es gerade nicht aktiv sein soll, dann bricht es die Verarbeitung einfach ab.
Es gibt aber zumindest einen eleganten Weg, herauszufinden, ob ein device disabled ist oder nicht:
Code Auswählen
{IsDisabled("at_nextion")}liefert eine 1 wenn das device "at_nextion" disabled ist.
Den Grund für das disable findest Du so aber auch nicht heraus.
#14
Automatisierung / notify Status während disabled...
Letzter Beitrag von yersinia - 11 März 2026, 15:47:45Ich hab eine (eher kosmetische, völlig unkritische) Frage zu notify in Verbindung mit disabledAfterTrigger und disabledForIntervals.
Ich nutze, vereinfacht, folgende funktionierende(!) notify Definiton:
Zwischen 20Uhr und 8Uhr benötige ich das notify gar nicht, daher disabledForIntervals.
Das alles funktioniert wie erwartet.
Was mich etwas verwirrt ist die Tatsache, dass ich im FHEMWEB nicht einfach erkennen kann, ob das notify Device gerade disabled ist (auf Basis der zwei Attribute) oder es keinen triggernden Event gab. STATE liefert die letzte Triggerzeit (mWn) und state, dass das notify aktiv ist:
Natürlich kann ich im Device nachsehen, wann der letzte Trigger war und es dann ausrechnen/abschätzen - aber gibt es auch einen eleganteren Weg zu erkennen, ob
- das notify Device gerade (temporär) disabled ist nach einem trigger (disabledAfterTrigger) aber nach Ablauf der Zeit (hier 30s) wieder aktiv lauscht?
- das notify Device gerade (temporär) disabled ist wegen (disabledForIntervals)?
- das notify Device nicht getriggert hat, weil es keinen passenden Event gegeben hat?
Generell sind STATE und state für mich so auch in Ordnung: ich finde es praktisch, dass STATE den letzten Trigger anzeigt. Ich finde auch den generellen state active passend, weil im Prinzip das Device auch nicht disabled/inactive und somit aktiv ist.
Ich nutze, vereinfacht, folgende funktionierende(!) notify Definiton:
Code Auswählen
defmod notify_test notify Device:.* { \
Log(3, "Yeah, Event triggered");;\
}
attr notify_test disabledAfterTrigger 30
attr notify_test disabledForIntervals 20:00-24:00 00:00-08:00Device generiert alle 60s Events für mehrere Readings (ist gewollt und imho ok); disabledAfterTrigger 30 nutze ich zum entprellen - also die Aktion nur einmalig auszuführen nachdem das erste Reading aus dem Device ein Event erzeugt hat.Zwischen 20Uhr und 8Uhr benötige ich das notify gar nicht, daher disabledForIntervals.
Das alles funktioniert wie erwartet.
Was mich etwas verwirrt ist die Tatsache, dass ich im FHEMWEB nicht einfach erkennen kann, ob das notify Device gerade disabled ist (auf Basis der zwei Attribute) oder es keinen triggernden Event gab. STATE liefert die letzte Triggerzeit (mWn) und state, dass das notify aktiv ist:
Code Auswählen
NOTIFYDEV Device
NR 474
NTFY_ORDER 50-notify_test
REGEXP Device:.*
STATE 2026-03-11 15:44:47
TRIGGERTIME 1773240287.61623
TYPE notify
READINGS:
2026-03-11 09:04:05 state active
Natürlich kann ich im Device nachsehen, wann der letzte Trigger war und es dann ausrechnen/abschätzen - aber gibt es auch einen eleganteren Weg zu erkennen, ob
- das notify Device gerade (temporär) disabled ist nach einem trigger (disabledAfterTrigger) aber nach Ablauf der Zeit (hier 30s) wieder aktiv lauscht?
- das notify Device gerade (temporär) disabled ist wegen (disabledForIntervals)?
- das notify Device nicht getriggert hat, weil es keinen passenden Event gegeben hat?
Generell sind STATE und state für mich so auch in Ordnung: ich finde es praktisch, dass STATE den letzten Trigger anzeigt. Ich finde auch den generellen state active passend, weil im Prinzip das Device auch nicht disabled/inactive und somit aktiv ist.
#15
ESP Familie / Aw: WLAN Lautsprecher auf ESP8...
Letzter Beitrag von romakrau - 11 März 2026, 15:45:03Nachdem ich den PAM8320A ausgetauscht habe spricht meine "Hedwig" wieder mit mir.
Die Software habe ich neu übersetzt und auf den WemosD1 hochgeladen.
Dabei waren die I2S Biliothek auf die Version 2.3 zurückzusetzen sowie der Treiber
für den CH340 auf die Version 3.4 downzugraden. Unter Win11 reagiert die Arduino IDE
sonst mit einem Fehler Code.
Die Software habe ich neu übersetzt und auf den WemosD1 hochgeladen.
Dabei waren die I2S Biliothek auf die Version 2.3 zurückzusetzen sowie der Treiber
für den CH340 auf die Version 3.4 downzugraden. Unter Win11 reagiert die Arduino IDE
sonst mit einem Fehler Code.
#16
MQTT / Aw: sonos2mqtt 3 von 4 Devices...
Letzter Beitrag von Otto123 - 11 März 2026, 15:39:51Zitat von: Flanders am 11 März 2026, 12:40:26Ich bin jetzt mal "illegaler Weise" hingegangenDas geht auch "legal" und mMn leichter über die Raw Definition: unten am Gerät zu finden, dann hat man einen Editor und kann die Änderungen vornehmen.
Zitat von: rudolfkoenig am 11 März 2026, 13:25:26Deswegen landet mit einem MQTT2_CLIENT alles ohne passende bridgeRegexp in einer MQTT2_DEVICE Sammel-Instanz.deswegen landet hier der config String im Bridge Device!? Würde bedeuten das regExp passt nicht, bzw. der MQTT2_Client liefert da etwas anderes.
#17
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von peterboeckmann - 11 März 2026, 14:48:55Danke, das Löschen hat geklappt.
Direkt danach ist die Skalierung des zweiten Balkendiagramms gestört. Nicht schlimm, gibt sich bestimmt wieder.
Vielleicht ein Ansatz für die Fehlersuche?
Dargestellt sollten dort Verbrauchsprognose und realer Verbrauch sein.
Viele Grüße,
Peter
Direkt danach ist die Skalierung des zweiten Balkendiagramms gestört. Nicht schlimm, gibt sich bestimmt wieder.
Vielleicht ein Ansatz für die Fehlersuche?
Dargestellt sollten dort Verbrauchsprognose und realer Verbrauch sein.
Viele Grüße,
Peter
#18
readingsGroup / readingsHistory / Aw: readingsGroup - longpoll A...
Letzter Beitrag von bertl - 11 März 2026, 14:47:49Jetzt habe ich noch weitere Tests gemacht und kann berichten, dass das NICHT-Aktualisieren nur dann auftritt, wenn die Varianten mit dem Index verwendet wird.
Commandref:
Somit gehe ich davon aus, dass das ein Fehler im Modul ist und hoffe auf die Hilfe des Modul-Verwalters justme1968
Commandref:
ZitatWenn der erste Regex '@<index>' ist, gibt es den Index der folgenden Regex an, mit dem die Messwerte gruppiert werden sollen. Wenn Erfassungsgruppen verwendet werden, können sie durch #<number> refferenziert werden. z.Bsp:
<IP-Adress><Hostname><MAC><Vendor>
nmap:@2,<#1>,(.*)_hostname,#1_macAddress,#1_macVendor
Somit gehe ich davon aus, dass das ein Fehler im Modul ist und hoffe auf die Hilfe des Modul-Verwalters justme1968
#19
Server - Linux / Aw: Zima OS für FHEM sinvoll ?
Letzter Beitrag von passibe - 11 März 2026, 14:45:59Zitat von: Loctite am 07 März 2026, 16:20:24Interessant wäre z.B. die App Immich für FotosicherungWas hält dich aktuell davon ab, Immich zu installieren? Docker kannst du auf quasi jeder Plattform betreiben ...
#20
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 11 März 2026, 14:43:18ZitatErinnere ich mich richtig, dass die Stunde, die um 12 begonnen hat, mit dem Index 13 gelöscht wird?Ja. Kannst dir einfach merken, es ist Stunde des Tagess (hour of day) beginnend mit 01 bis 24.
Und KI passt auch so.