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

[Matthias182]

Hallo zusammen,

ich habe ein merkwürdiges Problem und finde die Ursache einfach nicht selber.

Ich habe gerade meinen Pi3 und FHEM komplett neu aufgesetzt und angefangen FHEM einzurichten. Bisher sind nur meine Viessmann Heizung über VCONTROL300 und ein USB300 für ein paar Enocean (Eltako) Aktoren konfiguriert.

Nun ist es so dass im Wohnzimmer ein Aktor immer zur selben Zeit "eingeschaltet" wird. Im FileLog des fiktiven Schalters steht dann zu der Zeit:

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

Ich bin sicher, dass keiner den verbundenen Schalter betätigt hat, da zu der Zeit alle geschlafen haben.

Könnt ihr mir helfen die Ursache zu ergründen?


Danke und Gruß
Matthias

[marvin78]

Nur wenn du mehr Infos lieferst. Bitte die angepinnten Threads lesen. Darin findest du auch einen Abschnitt über Infos, die benötigt werden. lists von allen Devices, die mit dem Deckenstrahler zu tun haben, wären ein Anfang.

[Matthias182]

ok, hier auf jeden Fall schon mal das Listing des Deckenstrahlers:

Code Auswählen Erweitern



Save config
EnOcean
HWR
Unsorted
icoEverything Everything
Logfile
Commandref
Remote doc
Edit files
Select style
Event monitor

Internals:
   DEF        019E97A5
   IODev      USB300
   LASTInputDev USB300
   MSGCNT     3
   NAME       Deckenstrahler
   NR         35
   NTFY_ORDER 50-Deckenstrahler
   STATE      off
   TYPE       EnOcean
   USB300_DestinationID FFFFFFFF
   USB300_MSGCNT 3
   USB300_PacketType 1
   USB300_RSSI -92
   USB300_ReceivingQuality bad
   USB300_RepeatingCounter 0
   USB300_SubTelNum 3
   USB300_TIME 2018-08-29 07:11:51
   READINGS:
     2018-08-29 07:11:51   buttons         pressed
     2018-08-27 20:07:10   channelA        A0
     2018-08-29 07:11:51   channelB        BI
     2018-08-29 07:11:51   state           BI
   helper:
Attributes:
   IODev      USB300
   eventMap   BI:off B0:on
   manufID    7FF
   room       EnOcean
   subDef     FFA3BF81
   subType    switch
   switchMode pushbutton
   webCmd     on:off


Im FHEM Log (also nicht dem FileLog des Deckenstrahlers) finde ich zu dem Punkt leider keine weiteren Hinweise.

[marvin78]

Ich kenne mich mit EnOcean nicht aus. Da kann ich dir also nicht helfen.

Suche mal nach at's und notifys (DOIFs) in deinem System, die mit dem Device zu tun haben.

Aus meiner Sicht sehen die Log-Einträge erstmal nicht so aus, als wäre FHEM die Ursache für das Schalten. Aber ggf. bist du dann mit deiner Frage im entsprechenden Forum hier besser aufgehoben.

[Matthias182]

Ich wüsste nicht, was sonst die Ursache sein soll. Ich habe hier nur einen Wandschalter und den PI3 mit FHEM.

Meine FHEM.cfg ist noch sehr klein. Da könnte ich nur diese Einträge finden, die aber mit der Lampe nichts zu tun haben:

define WWTempAnDummy at +*00:00:05 { my $d= ReadingsVal("Heizung","WW-Temp-Oben",0);; fhem("set WWTempAktuell $d")}
define WWSollAnDummy at +*00:00:05 { my $d= ReadingsVal("Heizung","WW-Temp-Soll",0);; fhem("set WWTempSoll $d")}
define initialUsbCheck notify global:INITIALIZED usb create

[Thyraz]

Ich würde FHEM mal stoppen für eine Nacht und schauen ob die Lampe dann wieder an ist.
Dann weißt schonmal ob irgendwas in FHEM das auslöst, oder was anderes spinnt.

[mike1969bln]

Hat vielleicht ein Nachbar auch EnOcean und beim Einlernen wurden zufällig auch die Signale des Nachbarn empfangen? Dann ggf. den Aktor zurücksetzen und neu einlernen.


Gesendet von iPhone mit Tapatalk

[Matthias182]

So, habe dann gestern mal FHEM komplett ausgeschaltet und dann einen ganzen Tag gewartet, was passiert.

Schlussendlich ist der Spuk dann vorbei. Kein Licht das angeht.

Das legt natürlich den Verdacht nahe, dass etwas in FHEM die Ursache ist (Danke Thyraz für den Hinweis, manchmal sieht man den Wald .... nicht).

Jetzt bleibt aber immer noch zu ergründen, was FHEM da tut, zumal es eine ziemlich frische Installation ist. Habt ihr eine Idee, wie ich da weiter vorgehen könnte?

[Matthias182]

Hallo zusammen,

kaum war der Raspi und FHEM wieder im Netz aktiv, ging der Spuk mit dem Licht gestern wieder los.

Damit bin ich mir sicher, dass das der Auslöser ist. Nun bleibt aber noch die Frage, wo das verursacht wird on FHEM. Könnt ihr mir noch mal helfen da einen Ansatz zu finden?


Danke und Gruß
Matthias

[Matthias182]

Ja, es gibt eine Verbindung zu einem FileLog, das ich dort angelegt habe. Ansonsten aber nichts.

Meine FHEM.cfg ist noch nicht wirklich groß. Die kann ich hier einstellen:

Code Auswählen Erweitern


attr global userattr cmdIcon devStateIcon devStateStyle icon sortby webCmd webCmdLabel:textField-long widgetOverride
attr global autoload_undefined_devices 1
attr global logfile ./log/fhem-%Y-%m.log
attr global modpath .
attr global motd SecurityCheck:\
  telnetPort is not password protected\
  WEBphone is not password protected\
  WEB is not password protected\
  WEBtablet is not password protected\
\
Protect this FHEM installation by defining an allowed device with define allowed allowed\
You can disable this message with attr global motd none
attr global statefile ./log/fhem.save
attr global updateInBackground 1
attr global verbose 3

define telnetPort telnet 7072 global

define WEB FHEMWEB 8083 global
attr WEB editConfig 1

define WEBphone FHEMWEB 8084 global
attr WEBphone stylesheetPrefix smallscreen

define WEBtablet FHEMWEB 8085 global
attr WEBtablet stylesheetPrefix touchpad

# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog ./log/fhem-%Y-%m.log fakelog

define autocreate autocreate
attr autocreate filelog ./log/%NAME-%Y.log

define eventTypes eventTypes ./log/eventTypes.txt

# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
define ZWDongle_0 ZWDongle /dev/ttyACM0@115200
attr ZWDongle_0 homeId de7e91b2
define Heizung VCONTROL300 /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 ./89_VCONTROL300_VScotHO1.cfg 180 300
attr Heizung group Geräte
attr Heizung room HWR
define WWTempAktuell dummy
attr WWTempAktuell event-on-change-reading state
attr WWTempAktuell room HWR
define WWTempAnDummy at +*00:00:05 { my $d= ReadingsVal("Heizung","WW-Temp-Oben",0);; fhem("set WWTempAktuell $d")}
attr WWTempAnDummy room HWR
define FileLog_WWTempAktuell FileLog ./log/WWTemp-%Y-%m-%d.log Heizung:WW-Temp-Oben:.*
attr FileLog_WWTempAktuell logtype text
attr FileLog_WWTempAktuell nrarchive 5
attr FileLog_WWTempAktuell room HWR
define SVG_FileLog_WWTempAktuell_1 SVG FileLog_WWTempAktuell:SVG_FileLog_WWTempAktuell_1:CURRENT
define SVG_FileLog_WWTempAktuell_2 SVG FileLog_WWTempAktuell:SVG_FileLog_WWTempAktuell_2:CURRENT
attr SVG_FileLog_WWTempAktuell_2 room HWR
define doifWWTempup DOIF ([Heizung:WW-Temp-Oben] <= 40) (set Heizung WW-Temp-Soll 55)
attr doifWWTempup room HWR
define doifWWTempdown DOIF ([Heizung:WW-Temp-Oben] > 55) (set Heizung WW-Temp-Soll 10)
attr doifWWTempdown room HWR
define WWTempSoll dummy
attr WWTempSoll event-on-change-reading state
attr WWTempSoll room HWR
define WWSollAnDummy at +*00:00:05 { my $d= ReadingsVal("Heizung","WW-Temp-Soll",0);; fhem("set WWTempSoll $d")}
attr WWSollAnDummy room HWR
define FileLog_WWTempSoll FileLog ./log/WWTemp-%Y-%m-%d.log Heizung:WW-Temp-Soll:.*
attr FileLog_WWTempSoll logtype text
attr FileLog_WWTempSoll nrarchive 5
attr FileLog_WWTempSoll room HWR
define SVG_FileLog_WWTempSoll_1 SVG FileLog_WWTempSoll:SVG_FileLog_WWTempSoll_1:CURRENT
define USB300 TCM ESP3 /dev/ttyUSB1@57600
attr USB300 sendInterval 0
attr USB300 smartAckMailboxMax 0

define Deckenstrahler EnOcean 019E97A5
attr Deckenstrahler IODev USB300
attr Deckenstrahler eventMap BI:off B0:on
attr Deckenstrahler manufID 7FF
attr Deckenstrahler room EnOcean
attr Deckenstrahler subDef FFA3BF81
attr Deckenstrahler subType switch
attr Deckenstrahler switchMode pushbutton
attr Deckenstrahler webCmd on:off
define FileLog_Deckenstrahler FileLog ./log/Deckenstrahler-%Y.log Deckenstrahler
attr FileLog_Deckenstrahler logtype text
attr FileLog_Deckenstrahler room EnOcean
define FileLog_Leuchtstreifen FileLog ./log/Leuchtstreifen-%Y.log Leuchtstreifen
attr FileLog_Leuchtstreifen logtype text
attr FileLog_Leuchtstreifen room EnOcean
define Leuchtstreifen EnOcean 019F1AAF
attr Leuchtstreifen IODev USB300
attr Leuchtstreifen eventMap BI:off B0:on
attr Leuchtstreifen manufID 7FF
attr Leuchtstreifen room EnOcean
attr Leuchtstreifen subDef FFA3BF82
attr Leuchtstreifen subType switch
attr Leuchtstreifen switchMode pushbutton
attr Deckenstrahler webCmd on:off


[Beta-User]

Schau mal in's log, insbesondere ob zu der Zeit evtl. FHEM neu gestartet wurde. (Hast du einen Watchdog auf OS-Ebene laufen?)

[OT zur config]Was mir auf die Schnelle an Anregungen auffällt:- Alle USB-Geräte auf "by-id" umstellen (bisher 1/3)- die beiden doifWWTempup/downwürde ich zu einem Device zusammenfassen; kann ein DOIF sein, ginge aber auch z.B. mit einem THRESHOLD- initialUsbCheck solltest du deaktivieren (attr ... disable) oder löschen.[OT]

[Matthias182]

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:

Code Auswählen Erweitern


2018.08.30 18:55:24 3: Heizung device opened
2018.08.30 18:55:27 3: VCONTROL300: USB device closed
2018.08.30 18:58:24 3: VCONTROL300: USB connection opened
2018.08.30 18:58:24 3: Opening Heizung device /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
2018.08.30 18:58:24 3: Setting Heizung serial parameters to 4800,8,E,2
2018.08.30 18:58:24 3: Heizung device opened
2018.08.30 18:58:27 3: VCONTROL300: USB device closed
2018.08.30 19:01:24 3: VCONTROL300: USB connection opened
2018.08.30 19:01:24 3: Opening Heizung device /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
2018.08.30 19:01:24 3: Setting Heizung serial parameters to 4800,8,E,2
2018.08.30 19:01:24 3: Heizung device opened
2018.08.30 19:01:27 3: VCONTROL300: USB device closed


An der Qualität der Konfig werde ich auch noch arbeiten. Danke für deine Anregungen.

Watchdog sagt mir bisher nichts. Habe ich also vermutlich nicht.

[Markus.]

Hallo,

hatte mal ein ähnlich geartetes Problem. Hier war es eine Email die per Doif-Bedingung ausgelöst wurde. Ich habe die Bedingung über das WebIf gelöscht, also nicht per "CFG Editieren", aber die Mail wurde trotzdem immer versendet.

https://forum.fhem.de/index.php/topic,83689.msg759427.html#msg759427
Im Log oder in den Events war damals auch nichts zu finden, obwohl logolevel hoch.

Ich glaube ich habe damals alle DoIf's gelöscht dann war ruhe.

Gruß

Markus

[Beta-User]

Du hast aber nicht zufällig die Installation per ungesichertem Port-forwarding nach außen geöffnet? (Passwörter sind ja nicht gesetzt und es gibt kein "allowed"-Device...

Sonst könnte es sein, dass dir jemand drittes mitteilen will, dass das keine so tolle Idee ist.

[Markus.]

nee
Das komische war ja auch, das Ruhe war nachdem ich alle DoIf's gelöscht hatte und neu angelegt, nach einem Raspi Neustart.
Als wenn sich da irgendwo was in irgendeinem Cache festgesetzt hätte.