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
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.
ok, hier auf jeden Fall schon mal das Listing des Deckenstrahlers:
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.
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.
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
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.
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
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?
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
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:
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
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]
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:
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.
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 (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
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.
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.
@Markus.: Sorry, das war wohl missverständlich; die Frage nach dem Portforwarding richtete sich an den TE ;) .
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 ;-)
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.
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?
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.
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
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.
Ja, sorry, war nicht genau genug. Es passiert zwei Mal am Tag. Immer um 7:00 und 19:00.
(?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?
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ä.
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?)
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....
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.
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 (https://www.enocean-alliance.org/products/eeps/).
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.