[gelöst] FUD14 und FSG14 Einlernproblem

[zife]

Hallo,
nach Lektüre diverser Forenbeiträge, Starterguide, Enocean Commandrefs und stundenlangem Probieren wende ich mich jetzt doch verzweifelt an Euch.

Ich versuche, mehrere FUD14 und FSG14 (die an einem FAM14 hängen) über fhem zu steuern.

Zahlreiche andere Aktoren laufen problemlos, auch FUD61, etc.

Ich nutze einen TCM310 USB Stick am RasPi2, fhem ist aktuell.
Die Adressen sind per PCT14 überprüft. Der Aktor wurde testweise auch per autocreate angelegt und gemäss Commandref ergänzt, aber hilft nix...

Immerhin empfängt fhem auch Telegramme vom FUD14, wobei der Status beim Schalten immer nur kurz BI oder B0 ist und dann gleich auf 2 zurückspringt. (ist das normal?)

Das Problem: Einlernen am Aktor gelingt nicht. Wenn man den FUD14 auf PCT/LRN stellt, blinkt er endlos weiter, trotz "set ... teach" Kommando.

Ich habe es mit mehreren EEP versucht, mit und ohne "model Eltako_TF", immer dasselbe Ergebnis.

Empfang ist top, der RasPi liegt 2m neben den FUD14...


Hier das Listing:

Internals: DEF FFA7AC81
FUUID 5e5c145c-f33f-6ef9-d89e-907397ede1a125a5
IODev TCM_ESP3_0
LASTInputDev TCM_ESP3_0
MSGCNT 4
NAME LD_KU_Theke_FUD14
NR 255
NTFY_ORDER 50-LD_KU_Theke_FUD14
STATE 2
TCM_ESP3_0_DestinationID FFFFFFFF TCM_ESP3_0_MSGCNT 4 TCM_ESP3_0_PacketType 1 TCM_ESP3_0_RSSI -41 TCM_ESP3_0_ReceivingQuality excellent TCM_ESP3_0_RepeatingCounter 1 TCM_ESP3_0_SubTelNum 10 TCM_ESP3_0_TIME 2020-03-03 16:04:48 TYPE EnOcean

READINGS: 2020-03-03 16:04:48 D0 0
2020-03-03 16:04:48 D1 0
2020-03-03 16:04:48 D2 0
2020-03-03 16:04:48 D3 1
2020-03-03 16:04:47 buttons pressed
2020-03-03 16:04:47 channelB BI
2020-03-03 16:04:48 sensor1 2
2020-03-03 16:04:48 sensor2 0
2020-03-03 16:04:48 sensor3 0
2020-03-03 16:04:48 state 2
helper:
Attributes:
IODev TCM_ESP3_0
eep A5-38-08
gwCmd dimming
manufID 00D
model Eltako_TF
room EnOcean,EG Kueche
subDef FFBE4127
subType Gateway
teachMethod RPS
webCmd on:off:dim

Verbose 5 liegt auch vor, ich weiss nur nicht, wie viel ich davon hier posten soll, ist viel Text...

Kann jemand helfen bitte?

[Rainer S.]

Hallo,

ist vielleicht die Anzahl der 128 möglichen Sendeadressen erreicht?

Ich habe gestern problemlos mehrere FUD12 (habe nur die 12er-Serie) mit folgender Configuration eingelernt:

define bad_dimmer EnOcean FFA11099
setuuid bad_dimmer 5e5d2f1b-f33f-fc34-6720-7908ab767c925d7e
attr bad_dimmer IODev TCM310_0
attr bad_dimmer comMode uniDir
attr bad_dimmer eep A5-38-08
attr bad_dimmer gwCmd dimming
attr bad_dimmer manufID 00D
attr bad_dimmer room Bad
attr bad_dimmer subType gateway
attr bad_dimmer webCmd on:off:dim

Das zurückspringen des Sliders hatte ich auch kurzfristig. Nach einem reread der config.cfg und einem Neustart des Browsers war es aber dann weg und die Anzeige bzw. der Slider blieb auch dort stehen, wohin ich ihn geschoben habe.

[zife]

Das ist es (leider) nicht... am FAM14 hängen nur 5 Aktoren, und in fhem insgesamt sind es ca 40 Aktoren und 30 Sensoren (Taster, etc).

Der Rückfall auf Status "2" nach jedem Schalten ist auch nach diversen Neustarts vorhanden. Slider hab ich gar keinen, aber wozu auch, schon das Teach In in den Aktor scheitert ja...

[FHEM_newbie]

Hallo,

Versuch mal die eep komplett zu löschen, steht bei meinem funktionierenden FUD14 nicht drin. 
Und wie kommt die subDef zustande? Ist das dieselbe ID, die im PCT14 beim Dimmer als GVGS eingetragen ist?
Bei DEF habe ich bei mir die PCT14 Geräteadresse als HEX stehen und nicht wie es bei dir scheint die ID des Aktors. Nur vielleicht mal zum testen...

[zife]

Hm... das mit dem Löschen der EEP werd ich probieren (bin gerade nicht daheim).

Die DEF ist nicht die ID des Aktors sondern in der Tat die PCT14 Geräteadresse, die wird auch so beim autocreate erkannt.
Und Rückmeldungen empfängt fhem ja, also passt der Teil (sofern das Rückspringen auf Status 2 (s.o.) nicht ein Fehler ist).

Die subdef ist eine von mir vergebene ID, abgeleitet von der Base ID des TCM310 und lückenlos in HEX hochgezählt über alle im Einsatz befindlichen Aktoren. Im PCT14 steht die nicht drin, weil ja eben das Einlernen scheitert. Ein manuelles Eintragen in PCT14 ist mir nicht gelungen bzw. hat nicht gewirkt, aber der eigentliche Einlernprozess am Aktor (PCT/LRN) wäre doch eigentlich der richtige Weg?

Oder hab ich oben irgendwo einen Denkfehler?

[FHEM_newbie]

Hab's gerade nohchmal bei mir probiert die eep einzutragen, das ändert nichts an der Funktion.
Aber versuch doch mal deine SubDef manuell in eine Zeile des PCT14 einzutragen, mit der Funktion 32  Dimmwert von GFVS / Drehtaster. Vorausgesetzt die ist noch nicht wo anders vorhanden...

[zife]

Ich werds nochmal versuchen, hat aber beim letzten Mal nichts bewirkt.
Aber ich hab auch ein anderes Gerät als GFVS eingelernt, ist das ein Problem? Kann etwa nur ein einziges Gerät mit dieser Spec eingelernt werden?

[FHEM_newbie]

Das verstehe ich jetzt nicht ganz: du hast im FUD14 noch ein anderes GFVS eingelernt? Kein Problem! Der Aktor muss nur die subDef (die einmalig ist), eingetragen haben, damit er darauf reagieren kann wenn FHEM genau diese sendet.

[zife]

Genau so ist es, ich nutze noch eine andere Smarthome Zentrale, die ich erfolgreich als GFVS eingelernt habe. Aber klar, die nutzt ihre eigenen "subdefs". Die in fhem angegebene ist m.W. einzigartig.
Habs auch mit mehreren FUD14 mit verschiedenen subdef-Adressen probiert - immer erfolglos.

Das "kein Problem"  bzgl. 2 verschiedener "GFVS" freut mich - aber warum klappt das Einlernen dann nicht? Welches Brett hab ich vor dem Kopf und über welches Logfile o.ä. kann ich es finden?

[zife]

Oh, oh, oooooh... danke an alle, die sich mit meinem Problem beschäftigt haben - und Entschuldigung! Wie peinlich...

Rätselfetischisten aufgepasst: der Fehler steckt tatsächlich in meinen Attributen unten.

...
...
...
...

Ich habe "gateway" mit einem großen "G" geschrieben.

Ja, es war ein Brett, und zwar ein dickes. Thema erledigt.