FHEM schaltet Licht immer zu fester Zeit an (nicht gewollt)

Begonnen von Matthias182, 29 August 2018, 07:59:28

Vorheriges Thema - Nächstes Thema

Beta-User

@Markus.: Sorry, das war wohl missverständlich; die Frage nach dem Portforwarding richtete sich an den TE ;) .
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

Markus.

Zitat von: Beta-User am 31 August 2018, 11:50:20
@Markus.: Sorry, das war wohl missverständlich; die Frage nach dem Portforwarding richtete sich an den TE ;) .

Juppps hab ich zu spät gerafft ;-)

Matthias182

Ich hatte in der urpsrünglichen Konfiguration den Port geöffnet für die Implementierung von Alexa.

Nach der Neuinstallation habe ich aber auch die IP des Raspi gendert, um dem ganzen aus dem Wege zu gehen. Da sollte also von außen nichts dazu kommen.

Werde wohl doch mal einige Einträge löschen und sehen, ob das Auswirkungen hat.

Beta-User

Mach doch auch den Port am Router wieder zu und schau dir "allowed" an.

Und auch wenn es vielleicht eine doofe Frage ist: Läuft dein FHEM auch mit der config, die du gepostet hast oder evtl. mit einer anderen?

(Ich gehe nach deinen Schilderungen mal davon aus, dass du nur eine Hardware hast, auf der FHEM irgendwann mal gelaufen ist und du jetzt FHEM (oder das ganze OS?) neu installiert hast.)

Wenn da in FHEM nie mehr als die paar devices drin waren als die, die gepostet sind, dürfte das Löschen von irgendwas ziemlich zwecklos sein...
Sonstigen eigenen code (myUtils) hast du auch nicht im Einsatz, oder?
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

Matthias182

Zitat von: Beta-User am 31 August 2018, 12:20:12
Mach doch auch den Port am Router wieder zu und schau dir "allowed" an.

Das verstehe ich nicht, was meinst du mit "allowed"?

Zitat von: Beta-User am 31 August 2018, 12:20:12Und auch wenn es vielleicht eine doofe Frage ist: Läuft dein FHEM auch mit der config, die du gepostet hast oder evtl. mit einer anderen?

Die Kopie stammt aus der Oberfläche von FHEM, also unter dem Punkt Edit Files. Das sollte dann aus meiner Sicht das aktuelle sein.

Zitat von: Beta-User am 31 August 2018, 12:20:12
(Ich gehe nach deinen Schilderungen mal davon aus, dass du nur eine Hardware hast, auf der FHEM irgendwann mal gelaufen ist und du jetzt FHEM (oder das ganze OS?) neu installiert hast.)

Ja, da war vorher eine frühere Installation drauf, ich habe aber die SD-Karte formatiert und alles neu installiert.

Zitat von: Beta-User am 31 August 2018, 12:20:12
Wenn da in FHEM nie mehr als die paar devices drin waren als die, die gepostet sind, dürfte das Löschen von irgendwas ziemlich zwecklos sein...
Sonstigen eigenen code (myUtils) hast du auch nicht im Einsatz, oder?

Nein, ich habe bisher nur diese Devices angelegt und sonst nichts im Einsatz.

Beta-User

Nach deinen Schilderungen kann es eigentlich auch keine andere config sein (das ergibt sich aber nicht aus dem Hinweis zu "edit", sondern daraus, dass du ziemlich sicher nichts am Startscript von FHEM geändert hast ;) ).

Das ist und bleibt sehr rätselhaft...

Zu "allowed": https://wiki.fhem.de/wiki/Allowed
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

Pfriemler

Zitat von: Matthias182 am 29 August 2018, 07:59:28
2018-08-29_07:00:06 Deckenstrahler buttons: pressed
2018-08-29_07:00:06 Deckenstrahler channelB: on
2018-08-29_07:00:06 Deckenstrahler on

Zitat von: Matthias182 am 31 August 2018, 10:19:15
Das Ganze passiert immer ziemlich genau um 19:00. Zu der Zeit finde ich im Log aber keine Einträge außer von der VCONTROL300:

Das widerspricht sich jetzt aber.
"Ä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 ..."

Matthias182

Ja, sorry, war nicht genau genug. Es passiert zwei Mal am Tag. Immer um 7:00 und 19:00.

Beta-User

(?Du hast doch einen PI, oder?)
Stell mal die USB-Devices auf "by-id" um und schalte einen aktivenUSB-Hub dazwischen.

Diese beiden Termin klingen irgendwie danach, also würde zu 0:00 Uhr UTC und 12:00 Uhr UTC das OS irgend was machen. Vielleicht braucht der PI dann zusammen mit dem Einschalten des VCONTROL300 kurzzeitig zu viel Strom und der EnOcean-Stick kommt aus dem Tritt?

Was ist das für ein Netzteil? Irgendwelche Auffälligkeiten am PI? Was sagt dmesg?
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

Pfriemler

Zitat von: Beta-User am 31 August 2018, 14:12:46
... zusammen mit dem Einschalten des VCONTROL300 kurzzeitig zu viel Strom und der EnOcean-Stick kommt aus dem Tritt?
Wieso sollte der dann in Panik ausgerechnet ein genau passende Schaltkommando an einen Aktor senden - und immer an den gleichen? Nä.
"Ä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 ..."

Beta-User

Zitat von: Pfriemler am 31 August 2018, 14:32:32
Wieso sollte der dann in Panik ausgerechnet ein genau passende Schaltkommando an einen Aktor senden - und immer an den gleichen? Nä.
Zum einen dürfte es das geschilderte Phänomen eigentlich gar nicht geben, das schreit nach irgend was sehr Exotischem als Ursache, oder?

Hier hatte ich verstanden, dass das Schaltkomando ausgelöst wird im Zusammenhang mit einem _Tastendruck_?
Könnte das nicht die Antwort/Reaktion auf eine Statusabfrage sein? (Ich kenne EnOcean nicht, aber die Überlegung beginnt mit dem Gedanken, dass evtl. alle im Netz vorhandenen Geräte auf dem USB-Dongle gespeichert werden (ZWave macht das so, oder?) und das dann beim Start des Dongle für das gesamte Netzwerk eine solche Abfrage gibt?)
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

Pfriemler

Man könnte den Thread auch mal nach EnOcean verschieben ... wenn es denn EnOcean als Ursache ist. Oder mal dort fragen, was das sein könnte.
Ich hab nämlich auch keine Ahnung von EnOcean - bisher ist es nur ein Sensor, den ich betreibe. EnOcean besitzt ansonsten Direktverknüpfungen (funkt also ohne Broker).
Nochmal blöd zurückgefragt: Das ist ein Doppelbutton, mit dem Deckenlicht und Lichtstreifen getoggelt werden? Button und Aktor in einem Gerät? Ich finde kein EEP in der Def - das ist normalerweise der Gerätetyp. Den könntest Du alternativ auch einfach mal nennen....
"Ä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 ..."

Matthias182

Nein, den EEP habe ich nicht angegeben, da ich den Aktor als bidirektional eingelernt habe. Da bin ich dieser Anleitung gefolgt:

https://wiki.fhem.de/wiki/EnOcean_Starter_Guide#bidirektionale_Aktoren

Ich habe jetzt noch mal alles neu aufgesetzt und arbeite nun mit einer fast leeren fhem.cfg

Mal abwarten, ob damit alles so läuft wie erwartet.

Pfriemler

#28
Ne, den EEP meines Fenstergriffes musste ich nicht eingeben. Der kam beim von Dir beschriebenen bidirektionalen Anlernen ganz von allein nach FHEM. Bei Homematic wird so das "model" ermittelt und ins Attribut eingetragen - und das hatte ich vermisst. Hier kann man ebenfalls über das Profil Rückschlüsse auf den Typ und das Gerät selbst bekommen.

edit: Eine aktuelle Liste der EEPs findet sich hier.
"Ä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 ..."

Matthias182

So, ich habe die letzten Tage noch mal probiert, aber die wirkliche Ursache nicht finden können. Auch neues einlernen von FHEM in den Aktor hat nicht geholfen.

Schlussendlich habe ich nun auf einer neuen SD Karte alles noch mal installiert und angefangen FHEM zu konfigurieren. Dabei habe ich zuerst nur mit den beiden FSR61 Aktoren begonnen. Und siehe da, alles funktioniert wie vorher. Unterschied ist jetzt noch, dass die Einbindung meiner Heizung über das VCONTROL300.pm fehlt. Diese hatte ich beim letzten Versuch als erstes gemacht und dann erst die beiden Aktoren.

Bin mal gespannt, wenn ich jetzt die Heizung dazu nehme, ob das noch mal was ändert.

In jedem Fall euch allen vielen Dank für die Ratschlage und Unterstützung.