Hallo,
ich habe hier 2 Dinge, bei denen ich hoffe, dass mir da jemand helfen kann, den Fehler zu finden, bzw. was ich zur Ursachenfindung mit Hilfe von FHEM machen kann.
Zunächst Basis-Infos: FHEM als VM unter Proxmox unter Debian 9 (ja, schon alt, aber ab Debian 10 hatte ich Probleme mit dem EchoDevice, deswegen bin ich bei 9 geblieben), läuft in dieser Konstellation seit ca. 4-5 Jahren. ConBee II Stick läuft auf einem Rasbi 3 seit ca. 2 Jahren. nanoCUL seit ca. 3 Jahren. Die bisherige Suche über die Logdateien oder den Event-Monitor haben mich nicht weitergebracht, sieht alles plausibel aus.
Situation 1:
Aqara Fenster-\Tür-Kontakt (ZigBee über Conbee II Stick) schaltet eine Zwischensteckdose (Intertechno 433 MHz über nanoCul). Die Logik ist: tür auf, steckdose an, tür zu, steckdose aus (open = on, closed = off)
Fehlverhalten:
Die Steckdose schaltet zuverlässig an, aber random wieder aus. Also mal nach 10 sek. mal nach 30 sek. - immer ganz unterschiedlich.
Die absolut simple Logik:
KG_fl_tk_Kellertuer:.*
{
if ($EVTPART0 eq "open")
{
fhem("set testdummy $EVTPART0");
fhem("set KG.fl.SD.Licht on");
}
else
{
fhem("set testdummy $EVTPART0");
fhem("set KG.fl.SD.Licht off");
}
}
Hinweis:
Der Aqara Sensor wurde von mir getauscht. Es war vorher ein Homematic Classic Sec-SC-2 und damit hat es zu 99% immer funktioniert.
Fehlersuche:
Batterien wurden getest. Der Aqara zeigt zuverlässig an ob Tür geöffnet oder geschlossen ist, ich erkenne aber keine Schaltung, keinen Befehl oder sonstiges in FHEM, dass die Intertechno-Steckdose irgendwie ein "on-for-timer" sendet oder von "irgendwo her" ein Ausschaltbefehl kommt. Zumal ja auch die unterschiedlioche Dauer gar nicht dazu passt. Die Intertechno-Steckdose wird manuell über FHEM zuverlässig geschaltet.
Sitution 2:
HUE-Leuchte (über Conbee II) und IKEA TRÅDFRI Funk-Bewegungsmelder (ebenfalls Conbee II). Die Logik dahinter: Bei erkannter Bewegung schaltet die HUE für 180 sekunden das Licht an mit "on-for-timer".
Fehlverhalten:
Nach dem ersten Schaltvorgang geht die HUE für die besagten 180 Sekunden an, reagiert dann aber nicht mehr auf eine neue Bewegungserkennung vom Bewegungsmelder. Erst nach einer gewissen Zeit (noch nicht Minutengenau getestet, aber ich gehe von ca. 10 Minuten aus), reagiert die HUE wieder auf eine Bewegung. Aber da auch nur wieder auf die erste Erkennung.
Fehlersuche:
Batterien wurden getestet, Bewegungen werden einwandfrei erkannt, HUE-Leuchte lässt sich manuell über FHEM zuverlässig schalten.
Die Logik:
EG_bz_BM_BadUnten:.*
{
my $istTag = ReadingsVal("IstEsHell", "state", "0");
if ($EVTPART0 eq 'motion' && $istTag eq 0) {
fhem("set EG_bz_LA_BadUnten bri 60; set EG_bz_LA_BadUnten on-for-timer 180")
}
}
Info: Der Part "$istTag" ist nur eine Abfrage nach der Helligkeit draußen über den Conbee-Stick, hat aber mit dem Verhalten nichts zu tun.
Welche Möglichkeiten habe ich in FHEM, Licht ins Dunkel zu bringen? Loglevel? Debug?
Danke für eure Unterstützung
Gruß
Jörg
Zitat von: Goerch am 25 Januar 2024, 13:18:58Die absolut simple Logik:
Code Auswählen Erweitern
KG_fl_tk_Kellertuer:.*
{
if ($EVTPART0 eq "open")
{
fhem("set testdummy $EVTPART0");
fhem("set KG.fl.SD.Licht on");
}
else
{
fhem("set testdummy $EVTPART0");
fhem("set KG.fl.SD.Licht off");
}
}
Hinweis:
Der Aqara Sensor wurde von mir getauscht. Es war vorher ein Homematic Classic Sec-SC-2 und damit hat es zu 99% immer funktioniert.
Ich nehme an es handelt sich um ein notify?
Ganzes list würde das klären ;)
Gut es lauscht auf ALLE Events!!
Deine Logik: wenn "open", dann mach an / wenn "irgendwas anderes" dann mach aus <- ich denke da liegt das Problem.
Es kommen (vermutlich) Events die weder "closed" (wäre verm. das Gegenteil von "open") noch "open" (was ja für "an" genutzt werden soll) kommen.
Bei jedem Event, der nicht "open" heißt wird eben ausgeschaltet.
Z.B. es kommt ein Event "Battery" o.ä. -> aus 8)
Wenn du den Eventmonitor aufmachst, kannst du das sehen.
Entweder die Abfrage mit if/else(elsif) genauer machen oder gleich das notify besser einschränken.
Letzteres würde ich (zusätzlich) tun!
Du kannst dir im Eventmonitor auch notify etc. anlegen lassen und das sogar ganz spezifisch auf genau einen Event.
Gruß, Joachim
Zitat von: Goerch am 25 Januar 2024, 13:18:58Welche Möglichkeiten habe ich in FHEM, Licht ins Dunkel zu bringen? Loglevel? Debug?
Ich würde erst mal auch hier den Eventmonitor anwerfen:
Zitat von: Goerch am 25 Januar 2024, 13:18:58my $istTag = ReadingsVal("IstEsHell", "state", "0");
if ($EVTPART0 eq 'motion' && $istTag eq 0) {
Also, wenn der Wert nicht gelesen werden kann (warum auch immer), dann wird der Ersatzwert genommen -> "0".
Da es sich um einen numerischen Wert handelt: warum nicht ReadingsNum und als Ersatzwert 0 statt "0" <- Zeichenkette ;)
Dann beim Vergleich: eq ist für Zeichenketten == für numerische Werte.
Also in deinem Fall ist es "gemixt" aber da du mit einem numerischen Wert verleichst wohl eher == statt eq.
Ist bei Perl bzw. in deinem Fall nicht "tragisch", Perl ist da meist sehr komod.
Evtl. steht aber trotzdem was im Log...
Jetzt noch:
kommt denn vom Motion Sensor innerhalb der 180s wieder ein motion?
Weil: der BWM meldet motion -> Licht geht für 180s an / kommt dann erst nach (deutlich) mehr als 180s erst wieder ein motion, dann bleibt das Licht aus. <- Eventmonitor hilft hier
Oder: wenn das Licht aus ist reagiert dann das Licht auch nicht auf ein direktes Setzen per fhem-Oberfläche? <- dann muss man schauen warum das Licht tatsächlich nicht erneut angeht...
Gruß, Joachim
Hi,
Zitat von: Goerch am 25 Januar 2024, 13:18:58Fehlverhalten:
Nach dem ersten Schaltvorgang geht die HUE für die besagten 180 Sekunden an, reagiert dann aber nicht mehr auf eine neue Bewegungserkennung vom Bewegungsmelder. Erst nach einer gewissen Zeit (noch nicht Minutengenau getestet, aber ich gehe von ca. 10 Minuten aus), reagiert die HUE wieder auf eine Bewegung. Aber da auch nur wieder auf die erste Erkennung.
das kenne ich, dieses Verhalten haben einige Zigbee Bewegungsmelder, die sind mMn wirklich für für seltene Erkennung ohne weitere Logik zu gebrauchen.
Zitat von: Goerch am 25 Januar 2024, 13:18:58Welche Möglichkeiten habe ich in FHEM, Licht ins Dunkel zu bringen? Loglevel? Debug?
In Ergänzung zu Joachim, hier wird es alles etwas ausführlicher erklärt https://wiki.fhem.de/wiki/Notify
Gruß Otto
Hallo,
schon mal mit DOIF versucht?? Da gibt es das Attribut resetwait.
ZitatZurücksetzen des Waittimers für das gleiche Kommando
Im Gegensatz zu do always wird ein Waittimer mit dem Attribut do resetwait auch dann zurückgesetzt, wenn die gleiche Bedingung wiederholt wahr wird.
Damit können Ereignisse ausgelöst werden, wenn etwas innerhalb einer Zeitspanne nicht passiert.
Das Attribut do resetwait impliziert eine beliebige Wiederholung wie do always. Diese lässt sich allerdings mit dem Attribut repeatsame einschränken s. u.
Anwendungsbeispiel: Meldung beim Ausbleiben eines Events
define di_push DOIF ([Tempsensor])(set pushmsg "sensor failed again")
attr di_push wait 1800
attr di_push do resetwait
Es kommt nicht darauf an, womit man eine Aufgabe löst. Man sollte zuerst die Aufgabe möglichst klar beschreiben und im nächsten Schritt prüfen, welche Informationen man hat (oder im Ablauf eines events von FHEM geliefert werden) die bei der Lösung der Aufgabe helfen können.
Meines Erachtens sind beide Punkte hier noch nicht ausreichend geklärt.
Man könnte beispielsweise auch darüber nachdenken, ob man das hier:
my $istTag = ReadingsVal("IstEsHell", "state", "0");
einfach durch die von FHEM bereitgestellte Funktion (genauer: deren Rückgabewert) ersetzen könnte.
isday()
Zitat von: MadMax-FHEM am 25 Januar 2024, 13:28:40Ich nehme an es handelt sich um ein notify?
Ganzes list würde das klären ;)
Gut es lauscht auf ALLE Events!!
Deine Logik: wenn "open", dann mach an / wenn "irgendwas anderes" dann mach aus <- ich denke da liegt das Problem.
Es kommen (vermutlich) Events die weder "closed" (wäre verm. das Gegenteil von "open") noch "open" (was ja für "an" genutzt werden soll) kommen.
Bei jedem Event, der nicht "open" heißt wird eben ausgeschaltet.
Z.B. es kommt ein Event "Battery" o.ä. -> aus 8)
Gruß, Joachim
Das ist mir jetzt etwas peinlich, dass ich das übersehen habe. Der alte Homematic war im Gegensatz zum Aqara so schweigsam, dass mir das nicht aufgefallen ist...
Ich habe das mal angepasst und zumindest das Problem ist jetzt behoben - danke, man ist doch manchmal Betriebsblind.
Gruß
Jörg
Zitat von: MadMax-FHEM am 25 Januar 2024, 13:35:42Ich würde erst mal auch hier den Eventmonitor anwerfen:
Zitat von: Goerch am 25 Januar 2024, 13:18:58my $istTag = ReadingsVal("IstEsHell", "state", "0");
if ($EVTPART0 eq 'motion' && $istTag eq 0) {
Also, wenn der Wert nicht gelesen werden kann (warum auch immer), dann wird der Ersatzwert genommen -> "0".
Da es sich um einen numerischen Wert handelt: warum nicht ReadingsNum und als Ersatzwert 0 statt "0" <- Zeichenkette ;)
Dann beim Vergleich: eq ist für Zeichenketten == für numerische Werte.
Also in deinem Fall ist es "gemixt" aber da du mit einem numerischen Wert verleichst wohl eher == statt eq.
Ist bei Perl bzw. in deinem Fall nicht "tragisch", Perl ist da meist sehr komod.
Evtl. steht aber trotzdem was im Log...
Jetzt noch:
kommt denn vom Motion Sensor innerhalb der 180s wieder ein motion?
Weil: der BWM meldet motion -> Licht geht für 180s an / kommt dann erst nach (deutlich) mehr als 180s erst wieder ein motion, dann bleibt das Licht aus. <- Eventmonitor hilft hier
Oder: wenn das Licht aus ist reagiert dann das Licht auch nicht auf ein direktes Setzen per fhem-Oberfläche? <- dann muss man schauen warum das Licht tatsächlich nicht erneut angeht...
Gruß, Joachim
An und für sich hat der IKEA eine Cooldown-Zeit von ~180 Sekunden. Das passt soweit. Was nur merkwürdig ist - heute morgen ging es ohne Probleme und ohne das ich etwas geändert habe. Aber ich werde das mit den Varuablen mal abändern eq/== -evtl. ist da ja irgendwo der Wurm drin.
Danke & Gruß
Jörg
Zitat von: Otto123 am 25 Januar 2024, 13:49:43Hi,
das kenne ich, dieses Verhalten haben einige Zigbee Bewegungsmelder, die sind mMn wirklich für für seltene Erkennung ohne weitere Logik zu gebrauchen.
Bislang bin ich eigentlich mit der Trefferquote zufrieden. Hast du da eine Empfehlung?
Zitat von: Goerch am 25 Januar 2024, 13:18:58Welche Möglichkeiten habe ich in FHEM, Licht ins Dunkel zu bringen? Loglevel? Debug?In Ergänzung zu Joachim, hier wird es alles etwas ausführlicher erklärt https://wiki.fhem.de/wiki/Notify
Ja danke, ist bekannt. Ich kann es bald auswendig runterbeten. Aber manchmal denkt man einfach nicht auch mal um die Ecke um offensichtliches zu erkennen O:-)
Danke und Gruß
Jörg
Zitat von: betateilchen am 25 Januar 2024, 17:52:16Es kommt nicht darauf an, womit man eine Aufgabe löst. Man sollte zuerst die Aufgabe möglichst klar beschreiben und im nächsten Schritt prüfen, welche Informationen man hat (oder im Ablauf eines events von FHEM geliefert werden) die bei der Lösung der Aufgabe helfen können.
Meines Erachtens sind beide Punkte hier noch nicht ausreichend geklärt.
Man könnte beispielsweise auch darüber nachdenken, ob man das hier:
my $istTag = ReadingsVal("IstEsHell", "state", "0");
einfach durch die von FHEM bereitgestellte Funktion (genauer: deren Rückgabewert) ersetzen könnte.
isday()
Diese Funktion ist mir bekannt, aber da ich in einem anderen Szenario mit der Phoscon-Funktion arbeite (mehrere Abstufungen von Sonnenaufgang bis Sonnenuntergang in vielen Abstufungen), hatte mir das bisher gereicht. Aber trotzdem danke für den Hinweis.
Gruß
Jörg
Zitat von: Goerch am 25 Januar 2024, 13:18:58Situation 1:
Aqara Fenster-\Tür-Kontakt (ZigBee über Conbee II Stick) schaltet eine Zwischensteckdose (Intertechno 433 MHz über nanoCul). Die Logik ist: tür auf, steckdose an, tür zu, steckdose aus (open = on, closed = off)
Das liegt vielleicht auch an dem Intertechno-Protokoll, das schaltet bei mir auch nicht immer zuverlässig.
Eventuell hilft es im IT-Device den Wert des Attributs "ITrepetition" zu erhöhen (Defaultwert ist 6)
Guten Morgen,
erst einmal Danke an alle für das "schubsen" in die richtige Richtung. Das erste Problem wurde durch den Wink mit dem Zaunpfahl von Joachim geklärt (Die Logik reagierte auf ALLES und der Aqara erzählt sehr viel, was zu meinem Problem geführt hat). Habe die Bedingungen angepasst und jetzt scheint es zu laufen.
Das zweite Problem hat sich - warum auch immer - in Luft aufgelöst. Zumindest gestern Abend und heute Morgen schaltete alles wie gewünscht. Und ich habe wirklich nichts geändert!
Deswegen kann man hier wohl zu machen und für die Zukunft muss ich mir angewöhnen nicht auf bekanntes Verhalten zu achten, sondern die aktuellen Fakten zu betrachten.
Nochmal Danke und Gruß
Jörg
Zitat von: dkreutz am 26 Januar 2024, 08:38:38Zitat von: Goerch am 25 Januar 2024, 13:18:58Situation 1:
Aqara Fenster-\Tür-Kontakt (ZigBee über Conbee II Stick) schaltet eine Zwischensteckdose (Intertechno 433 MHz über nanoCul). Die Logik ist: tür auf, steckdose an, tür zu, steckdose aus (open = on, closed = off)
Das liegt vielleicht auch an dem Intertechno-Protokoll, das schaltet bei mir auch nicht immer zuverlässig.
Eventuell hilft es im IT-Device den Wert des Attributs "ITrepetition" zu erhöhen (Defaultwert ist 6)
Danke für den Hinweis. Ich habe noch 2 von diesen Steckdosen im Einsatz, welche aber jetzt auch zeitnah ersetzt werden. Die fehlende Rückmeldung ob geschaltet oder nicht, wird in meiner Konstellation immer mehr zum Problem, da ich immer verrücktere Ideen habe :)
Sorry, nochmal eine Frage wie ich das Thema auf "gelöst" setzen kann.
ersten Beitrag den Betreff editieren ;)