Hallo ihr,
ich habe seit einiger Zeit ein FAH60 (Aussen Helligkeitssensor) von Eltako bei mir im Betrieb.
Seit einiger Zeit kommt es immer wieder vor, dass er seine Eigenschaften und sein Format auf "raw" umschaltet.
Wenn ich das verfolge, sehe ich im Event-Log, dass dieser Sensor ein Teach-In ausggelöst hat.
Es kommt zu Meldungen wie:
2015.01.02 03:33:49.519 2: EnOcean Helligkeit.Aussen teach-in EEP A5-3F-3F Manufacturer: Multi user Manufacturer ID not supported
2015.01.10 00:05:26.701 2: EnOcean Helligkeit.Aussen teach-in EEP A5-3F-7F Manufacturer: Multi user Manufacturer ID
2015.01.23 05:04:51.925 2: EnOcean Helligkeit.Aussen teach-in EEP A5-3F-7F Manufacturer: Multi user Manufacturer ID
2015.02.05 16:21:26.212 2: EnOcean Helligkeit.Aussen teach-in EEP A5-1A-3A Manufacturer: 5FF not supported
2015.02.07 10:12:00.337 2: EnOcean Helligkeit.Aussen teach-in EEP A5-1D-1A Manufacturer: 0FF not supported
Ich habe versucht das mit "Autocreate disable=1" auszuschalten, aber es kam erneut vor.
Ich habe im Enocean Empfangsmodul den "Learning Mode" auf "Demand" gestellt. Trotzdem trat es wieder auf.
Habt ihr evtl noch Ideen, wodurch dass ausgelöst werden könnte und wie ich ein entsprechendes Umschalten ggf. verhindern könnte?
Danke für etwaige Antworten.
Gruß
Sven
Sobald ein 4BS-Sensor (EEP A5-??-??) eingelernt ist, werden nachfolgende teach-in Telegramme immer empfangen und ausgewertet. Die gelogten Telegramme passen nicht zu einem Eltako-Sensor. Bei diesen fehlerhaften teach-in schaltet Fhem auf das raw-Profil, das ist so gewollt. Meine erste Vermutung: Der Sensor ist defekt.
Die Werte, die der Sensor liefert sind in Ordnung und plausibel, wenn er im richtigen Modus läuft.
Ich benutze auch eine Repeater. Besteht evtl dort die Möglichkeit einesProblems?
Welche Möglichkeiten habe ich noch dem Phänomen auf die schliche zu kommen?
Gruß
Sven
Es kann natürlich einen Sender geben, der mit der gleichen SenderID teach-in Telegramme sendet. Das kann aber nur vorkommen, wenn man einen Transceiver, wie er an Fhem eingesetzt wird, bewusst auf diese Adresse legt; eher unwahrscheinlich. Ein Repeater verändert kein Telegramm, kommt deshalb als Ursache auch nicht in Frage. Für mich kommt deshalb nur der Sensor selbst als Fehlerquelle in Frage.
Hallo,
exakt das gleiche Verhalten hatte ich schon zweimal mit einem Eltako FBH63AP.
Dieser hat selbstständig ein Lerntelegramm geschickt FHEM hat ihn mit einer falschen manufID und EEP angelernt und die bestehende Konfiguration damit überschrieben.
Das Gerät lieferte anschließen natürlich keine passenden Readings mehr.
Nach einer mauellen Korrektur der Attribute lief es dann wieder.
mfg
Helmut
Hallo,
aktuell hat mein FBH63AP wieder ein Lerntelegramm an FHEM gesendet. Dieses hat ihn dann erneut mit manufID 4FF , EEP A5-0E-3E und subType raw eingelernt und die bisherige Konfiguration überschrieben.
Habe es wieder manuell korrigieren müssen. :(
Nach der Korrektur läuft es wieder.
mfg
Helmut
Hallo Helmut,
kannst Du das nicht als "Notlösung" mit einem passenden notify abfangen und bei Teach-In richtige Werte setzen lassen?
Interessanterweise hatte ich das Teach-In-Problem mit manufID 4FF vor ein paar Wochen mit einem PEHA EBIM-Aktor, habe es aber nicht weiter verfolgt, da es bisher einmalig war.
Gruß, Christian
Hallo,
mit notify ist eine gute Idee!
Wie würde das denn beispielsweise aussehen?
mfg
Helmut
Mehr geraten, als gewußt, da ich den Sensor nicht kenne und derzeit auch nicht testen kann:
define nFehler notify <device>:teach-in.* attr <device> manufID 00D; attr <device> subType lightTempOccupSensor.01
Den Code an Dein Device anpassen und dann mal mit trigger anhand der Ausgaben in Deinem Log zum fehlerhaften Telegramm testen und berichten.....
Hallo,
ich habe das notify übernommen und angepasst.
Da ich ca. alle 14- 20 Tage ein unerwünschtes Teach-in bei dem Sensor hatte, werden wir bald wissen, ob der Workaround funktioniert!
Danke!
Bei einem in Fhem eingerichteten unidirektionalen Device vom Typ RORG 4BS wurden bisher empfangene teach-in Telegramme immer ausgeführt. Ich habe die Routinen jetzt geändert. Mit dem nächsten Update werden solche Telegramme nur ausgeführt, falls der Transceiver im "teach"-Mode ist.
Damit ist das Grundproblem, dass der Sensor falsche teach-in Telegramme sendet, natürlich nicht beseitigt.
Hallo,
ich hoffe es ist kein Problem das ich mich an diesen alten Thread ranhänge. Ich habe genau die gleichen Probleme wie hier geschrieben, allerdings von allen möglichen Sensoren/Aktoren. Mal ist es der eine Heizkörper, dann der nächste, dann mal ein Helligkeitssensor, mal ein Raumsensor....
Ich schätze auch mal so alle paar Wochen (völlig sporadisch) steigt ein Sensor aus und meldet zum Beispiel:
teach 4BS teach-in accepted: No EEP profile identifier and no Manufacturer ID
und setzt eben auch den SubType auf RAW. EEP und Manufacturer wären in der config aber noch richtig. Wenn dieser SubType wieder manuell angepasst wird (oder auch durch drücken der Taste auf dem Enocean device), stimmen auch alle Werte wieder.
Warum genau das ganze passiert habe ich bis heute nicht verstanden, die Sensoren sind ja nicht defekt und laufen ja wenn alles richtig eingestellt ist ohne Probleme und teilweise auch monatelang ohne Störung. Funkstörungen? Betrifft aber auch Sensoren die nicht mal einen Meter vom Raspi entfernt sind. Und vorallem, warum korrigiert sich der Sensor in FHEM dann nicht beim nächstem erhaltenem Wert? Ich mag jetzt auch nicht für jedes device hier ein Korrektur notify anlegen, da ja irgendwie schon fast alle mal betroffen waren, daher die Frage, gibt es noch Möglichkeiten das erneute Teach-In abzuschalten, oder andere Lösungsansätze? Vielleicht versteh ich das mit dem Transreceiver im teach Modus aus vorherigem post auch falsch. Kann ich denn global abschalten (bzw. wo prüf ich das ob der auch wirklich aus ist was ich aber eigentlich vermute da ich immer mit "set TCM_ESP3_0 teach 600" arbeite).
Grüße Floon
Damit teach-in Telegramme nur dann ausgewertet werden, während der learning-mode eingeschaltet ist, muss das Attribut
attr <name> learningMode demand
gesetzt oder gelöscht sein (Standardeinstellung).
Super Danke! Gefunden. Da war bei mir, warum auch immer, tatsächlich was anderes gesetzt.