(gelöst)HM-MOD-Re-8 bei FHEM-Neustart

Begonnen von laxmann, 08 November 2017, 19:19:02

Vorheriges Thema - Nächstes Thema

laxmann

Hallo zusammen,
ich benutze drei HM-MOD-Re-8 als Fernbedienungen zur Meldung an das FHEM-System:
Schlafengehen
Ausfstehen
Weggehen
Heimkehren
Diese Programme funktionieren an allen drei Fernbedienungen einwandfrei.

Eine Fehlfunktion ist mir nun aufgefallen.
Beim Neustart von FHEM werden die Programme der o.g Optionen
Schlafengehen
Ausfstehen
Weggehen
Heimkehren
durchlaufen. Dies ist in der Logfile aufgezeichnet.
Daraufhin habe habe ich alle Fernbedienungen HM-MOD-Re-8 außer Betrieb genommen - da war beim Neustart von FHEM alles in Ordnung.
Dann habe ich die erste Fernbedienung (HM-MOD-Re-8) wieder in Betrieb genommen. Und schon wurden beim Neustart die o.g. verschiedenen Programme abgearbeitet.

Die FHEM-Wiki gibt nicht viel her.
Hier meine Fragen:
Was macht FHEM mit HM-MOD-Re-8 bei einem Neustart?
Gibt es ein Attribut, das die Reaktion des HM-MOD-Re-8 bei einem Neustart von FHEM unterbindet?

Gruss
laxmann

MadMax-FHEM

Wie startest du deine "Programme"?
Notify? Poste doch mal ein list davon (in code-Tags, das '#' im Menü)

Poste doch mal ein list eines HM-MOD-Re-8.

Evtl. wird bei Fhem-Start ein "StatusRequest" abgesetzt (das ließe sich evtl. mit autoReadReg unterbinden 0_off) und evtl. reagiert daraufhin das Notify für die "Programme"...

Oder etwas beim state-File-Einlesen...

...oder es gibt ein Register wo sich das Verhalten einstellen lässt (aber du hast das Problem ja bei einem fhem Neustart und nicht bei einem Neustart des HM-MOD-Re-8)

Aber ohne mehr Info nur mal ins blaue geschossen...

Ich habe ein HM-MOD-Em-8 und habe sowas noch nicht beobachtet

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Pfriemler

Ähm ... Du nutzt drei Re-8 per manueller Triggerung (Ein- und Ausschalten der Ausgänge per lokalem Tastendruck), um über diesen Zustand FHEM etwas mitzuteilen? Deine Programme sollten doch nur bei Änderung reagieren, d.h. ein "event-on-change-reading.*" in den Kanälen wäre schon Pflicht.

An das statefile habe ich auch gleich gedacht, aber da würde es bei mir vermutlich auch pausenlos klingeln beim Neustart... ich glaub, das erzeugt keine Events.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

MadMax-FHEM

Zitat von: Pfriemler am 08 November 2017, 23:30:37
An das statefile habe ich auch gleich gedacht, aber da würde es bei mir vermutlich auch pausenlos klingeln beim Neustart... ich glaub, das erzeugt keine Events.

Jep aber bei der gewaltigen Informationsflut musste ich ein wenig "improvisieren" ;)

Das mit den Notify war ja auch nur geraten...
...wahrscheinlich ist es DOIF ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

laxmann

Hallo und guten Morgen,
Joachim, ich habe
ZitatEvtl. wird bei Fhem-Start ein "StatusRequest" abgesetzt (das ließe sich evtl. mit autoReadReg unterbinden 0_off) und evtl. reagiert daraufhin das Notify für die "Programme"...
als erstes ausprobiert - und schon funktioniert es.
Ich habe sicherlich auch so eine Situation
ZitatJep aber bei der gewaltigen Informationsflut musste ich ein wenig "improvisieren" ;)
Daran muss ich noch arbeiten.

Danke
Gruss laxmann

MadMax-FHEM

Eventuell auch mal das Notify oder wie immer du die Programme startest posten, also list NotifyName und die Ausgabe dann hier in code-Tags (das '#' im Menü)...

Evtl. lässt sich da auch was optimieren, ich denke es reagiert evtl. auf zu viel...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Pfriemler

Genau ... ein autoReadReg darf die Funktion der Programme nicht stören. Das ist Doktern am Symptom. Mein Vorschlag steht ja schon weiter oben.

Gesendet von meinem SM-T813 mit Tapatalk

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

laxmann

Hallo zusammen,
ich habe mir meine "Konstruktion" zu
Schlafengehen
Aufstehen
Weggehen
Heimkehren
mal genauer angeschaut und musste feststellen, dass ich zu Beginn meiner FHEM-Aktivitäten FS20-Funkfernbedienung und -Funksteckdosen benutzt habe. Da diese aber sehr unzuverlässig schalteten, habe habe ich auf HM umgestellt. Bei dieser Umstellung aber die "Konstruktion" von der nicht mehr existierenden FS20-Funkfernbedienung in diesem System weitergenutzt. Diese Schaltung  der indirekten Nutzung hat auch sehr gut funktioniert, bis ich dann die HM-MOD-Re-8 in diesem System mit eingebunden habe.
Euere Hinweise haben mich veranlasst, dieses System auf DOIF umzustellen und das System zu bereinigen.
Wobei ich auch der Meinung bin, dass nur bei einem Event (Tastendruck) etwas passieren darf.
Ich schaffe jetzt erstmal Ordnung, wenn dann alles im Bestenfall gut läuft, werden ich mich melden, wenn nicht, dann bin ich auf sowieso wieder dabei.

Gruss
laxmann

MadMax-FHEM

Na dann...

...viel Erfolg, Joachim

...und vielleicht bis bald... ;)
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

laxmann

#9
Hallo zusammen,
ich habe nun alles umgeschrieben.
Der Fehler ist geblieben beim FHEM-Neustart.
Dann habe ich von Pfriemler mal
Zitatd.h. ein "event-on-change-reading.*" in den Kanälen wäre schon Pflicht.
durchgeführt. Siehe da - Schluss mit den durch die Fernbedienungen verursachten Fehlern beim Neustart.
Ist das nun so zu aktzepieren, reicht das event-on-change-reading?


Gruss
laxmann

MadMax-FHEM

Da wir keine Ahnung haben was du geändert hast und wie dein Notify aussieht können wir nichts sagen...
...akzeptabel liegt immer im Auge des Betrachters...

Wenn es für dich tut ist es doch ok.

Ob es "besser" ginge (wobei besser geht wohl immer ;)  ) kann man halt nur beurteilen, wenn man preisgibt wie es ist ;)

Aber nur als Anmerkung: die Regex eines Notify sollte halt immer möglichst genau das "treffen" was "gesucht" ist (also was auslösen soll). Je weiter das Notify greift, desto öfter reagiert es und dann kann es zu "Fehlauslösungen" kommen (und nat. mehr Last) die man dann eben anderweitig abfangen muss...
...oder halt gleich richtig definieren...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

laxmann

Hallo Joachim,
wie ich oben schon erwähnt habe, war mein frühere Konstruktion nur über umWege zu erreichen. Dins habe ich nun beseitigt.
Regex der vier Kanäle steuern ein Dummy mit vier unterschiedlichen Werten
(HM_FB_1_Sw(HM_FB_1_Sw_01|HM_FB_2_Sw_01|HM_FB_3_Sw_01):(on|off)_01|HM_FB_2_Sw_01|HM_FB_3_Sw_01):(on|off) set Dummy1 Aufstehen
Die anderen Kanäle der drei HM-MOD-Re-8 entsprechend.
Dummy1 steuert dann den passenden DOIF.
Geht es noch besser?

Gruss
Uwe

MadMax-FHEM

#12
Hi Uwe,

also ich hab mir das Notify (war/ist doch eins!?) angeschaut, ein wahnsinn...

Das geht auf jeden Fall einfacher...

Weil da ist soviel verklammert und verodert, das muss einfacher auch gehen...

Besser du beschreibst in Worten was denn erreicht werden soll, Beispiel:

Bei Druck auf Taste eins der FB soll der Dummy auf Aufstehen gehen
Bei Druck auf Taste zwei soll...

Und dann das "Zweistufige" ist auch eher eigenartig, also warum setzt du per (sehr eigenartig formuliertem) Notify einen Dummy um dann per DOIF weiter zu machen??

Daher evtl. sogar ganz konkret in Einzelbeschreibungen schildern was genau du eigentlich erreichen willst oder (dann muss "reverse Engineering" betrieben werden) du postest alles was du hast also alle Notify, Dummy und DOIF die zur Steuerung da sind, dann kann man was dazu sagen...

Denn ein Notify zu posten und dann nur zu sagen die anderen machen es ähnlich nur mit anderen Werten hilft nicht die "Logik" zu erkennen die dahinter steckt (stecken soll)...

Aber nochmal: wenn es geht ist es erst mal ja ok. Besser wird immer gehen... Aber das hier scheint schon umständlich zu sein ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

laxmann

#13
Hallo Joachim,
dein vorgeschlagener Weg jede einzelne Aktion hatte ich vorher und hatte zur folge - immer unübersichtlicher.

ZitatUnd dann das "Zweistufige" ist auch eher eigenartig, also warum setzt du per (sehr eigenartig formuliertem) Notify einen Dummy um dann per DOIF weiter zu machen??
habe ich deshalb gewählt, weil die schreibweise als notify viel einfacher und übersichtlicher ist. Als DOIF hätte ich dafür 2x3x4 (on/off, 3 Fernbedienungen und vier Kanäle) also 24 DOIF-Anweisung schreiben müssen.
Hier meine vier Notify's für den Dummy
(HM_FB_1_Sw_01|HM_FB_2_Sw_01|HM_FB_3_Sw_01):(on|off) set Anwesenheitssteuerung Aufstehen

(HM_FB_1_Sw_04|HM_FB_2_Sw_04|HM_FB_3_Sw_04):(on|off) set Anwesenheitssteuerung Heimkehren

(HM_FB_1_Sw_02|HM_FB_2_Sw_02|HM_FB_3_Sw_02):(on|off) set Anwesenheitssteuerung Schlafengehen

(HM_FB_1_Sw_03|HM_FB_2_Sw_03|HM_FB_3_Sw_03):(on|off) set Anwesenheitssteuerung Weggehen


Hier das DOIF für den Dummy zur Auslösung der Aktionen
([Anwesenheitssteuerung:state] eq "Aufstehen") (set ST_17 on-for-timer 1, set TempReglerWohnzimmer_Climate:FILTER=desired-temp!=8.0 desired-temp 19, set Thermostat_Bad_Hinten_Clima:FILTER=desired-temp!=8.0 desired-temp 22, set TempReglerBad_Vorne_Climate:FILTER=desired-temp!=8.0 desired-temp 19.0)
DOELSEIF ([Anwesenheitssteuerung:state] eq "Schlafengehen") (set TempReglerWohnzimmer_Climate:FILTER=desired-temp!=8.0 desired-temp 16, set Thermostat_Bad_Hinten_Clima:FILTER=desired-temp!=8.0 desired-temp 16, set TempReglerBad_Vorne_Climate desired-temp 16.0)
DOELSEIF ([Anwesenheitssteuerung:state] eq "Weggehen") (set ST_11_Sw on, set ST_12_Sw on, set Jalousie_Unten.hoch inactive, set Jalousie_DuscheUnten off, set Jalousie_ZimmerUnten off, set KellerFensterAufZu inactive, set HM_Win level lock, set TempReglerBad_Vorne_Climate controlManu 16.0 set TempReglerWohnzimmer_Climate controlManu 16.0 set Thermostat_Bad_Hinten_Clima controlManu 16.0)
DOELSEIF ([Anwesenheitssteuerung:state] eq "Heimkehren") (set ST_11_Sw off, set ST_12_Sw off, set TempReglerWohnzimmer_Climate:FILTER=desired-temp!=8.0 desired-temp 19, set Thermostat_Bad_Hinten_Clima:FILTER=desired-temp!=8.0 desired-temp 20, set TempReglerBad_Vorne_Climate controlMode auto, set TempReglerWohnzimmer_Climate controlMode auto, set Thermostat_Bad_Hinten_Clima controlMode auto, set KellerFensterAufZu active, set Jalousie_Unten.hoch active)

Den Dummy habe ich gewählt, weil die zwei Tablets, das Smartphone und die drei Fernbedienungen wunderbar darauf zugreifen können.
Den DOIF, weil die umfangreichen Aktionen hiermit am besten und übersichtlicher darstellen lässt.

Was für mich immer noch unerklärlich erscheint, ist das Triggern der Fernbedienungen beim Start von FHEM und das dies durch "event-on-change-reading" abgefangen werden kann.

Gruss
Uwe

MadMax-FHEM

Pack doch bitte das DOIF auch in code-Tags...
(geht auch nachträglich: bearbeiten)

Einfacher ist trotzdem (meist) beschreiben was du erreichen willst (zusätzlich zu den lists)...

Ich selbst nutze DOIF nicht, ich nutze für "Entscheidungen" (Logik was passieren soll wenn) einfach sub in myUtils, also selbstgeschriebene Funktionen die ich dann per Notify aufrufe, übergebe was ich brauche und die Logik mache ich dann dort.
Und meist fang ich an mit Ausgaben (Log) was ich übergeben bekomme, dann weiß ich was ich hab... ;)

Und mit weiteren Logausgaben kontrolliere ich dann den Ablauf der Logik...

Wie gesagt mein Weg...

Und wie gesagt, wenn es läuft und du es verstehst ist es erst mal gut für dich...

Optimierung kommt mit der Zeit...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)