Restart von Fhem bewirkt Kommandierung von Aktoren (e.g. Jalousie, Mähroboter et

Begonnen von Hackstall, 13 Juni 2020, 10:51:01

Vorheriges Thema - Nächstes Thema

Hackstall

Hallo,

ich habe seit geraumer Zeit das Problem dass meine Autoren (8266, Mähroboter, Jalousien) irgendwie kommandiert werden wenn ich einen Restart von Fhem durchführe.
Das ist echt nervig wenn der Mähroboter ungewollt anfährt, die Jalousien kurz hoch und heruntergefahren werden und die Lichtsäulen im Garten (8266) ein uns ausgeschaltet werden.

Dieses beobachte ich schon seit geraumer Zeit und hatte es bisher ignoriert. Die Kommandierung war zu Beginn von "meiner" FHEM Aktivität noch nicht.

Gibt es hier ein Setting welches eine Kommandierung nach REboot verhindert. Ich denke es muss wohl irgendwie mit der Initialisierung zusammenhängen, oder?

Irgendeine Idee?

Danke Andreas

MadMax-FHEM

Wie findet denn die "Kommandierung" statt!?

Notify? DOIF? ...?

Alle mit dem selben Modul!?

Sauber runter gefahren!?

state-File (fhem.save) sauber geschrieben!?

Evtl. schon mal im Forum gesucht!?

Bzgl. DOIF (zwar nicht Ausführung aber vielleicht ja ähnlich): https://forum.fhem.de/index.php/topic,105258.msg991923.html#msg991923

EDIT: also vielleicht ein Attribut gesetzt, was z.B. bei einem "Define/Initialiseirung" (das passiert ja beim Starten) zu einer "Neuberechnung" führt!?

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)

Hackstall

Halöo,

commanding findet an mehreren Stellen statt:
-notify, douf: Ja
-runtergefahren mit : shutdown restart

- state-file: was ist das und wann und wie wird es geschrieben

Attribut: ?

Mir ist nicht klar was FHem beim shutdown macht und was Fhem beim restart macht.
Kann man das nachlesen oder gibt es eine guideline?

Danke Andreas

MadMax-FHEM

Ja kann man nachlesen: Forum, Wiki, comandref

Schön, dass du so ausführlich schreibst...
...vielen Dank dafür... ;)

statefile wird norm. bei einem sauberen shutdown geschrieben...

Manche speichern das auch "einfach so" immer wieder mal...


Beim Start wird das statefile gelesen und sollte somit die gespeicherten Zustände wieder herstellen...

Kann z.B. sein, dass ein verw. das Modul das nicht macht, sonstwas nicht stimmt, ...

Aber mit den gegebenen Infos kann ich nicht mehr sagen...

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)

KölnSolar

Ich spekulier mal mit:
ZitatBeim Start wird das statefile gelesen und sollte somit die gespeicherten Zustände wieder herstellen...
und wenn es falsch ist bzgl. at/Doif(?) werden die so oft ausgeführt bis der aktuelle timestamp erreicht ist. Sollte man aber im Log erkennen können.
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Beta-User

Nach der Art der genannten Aktoren könnte es auch an "retain" liegen. Ansatzpunkte hier: https://forum.fhem.de/index.php/topic,112018.0.html

Aber auch von meiner Seite: Ohne nähere Info kann man einfach nur spekulieren...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors