4BS teach-in is missing

Begonnen von cwagner, 26 Dezember 2024, 15:30:07

Vorheriges Thema - Nächstes Thema

cwagner

Habe schon viele Dutzend EnOcean-Devices an meinem USB-310-Stick (Busware) erfolgreich angelernt und bin nun am verzweifeln: Habe mir zu Weihnachten drei weitere Micropelt MVA-005 gegönnt und kriege diese Heizkörper-Aktoren zum verrecken nicht korrekt angelernt: 2024.12.26 14:13:13 5: TCM TCM_ESP3_0 received ESP: 55000A0701EBA509A62B2E05890FC78003FFFFFFFF2E00E9
2024.12.26 14:13:13 5: TCM_ESP3_0: dispatch EnOcean:1:A5:09A62B2E:05890FC7:80:03FFFFFFFF2E00
2024.12.26 14:13:13 5: EnOcean received via TCM_ESP3_0: EnOcean:1:A5:09A62B2E:05890FC7:80:03FFFFFFFF2E00
2024.12.26 14:13:13 1: EnOcean Unknown device with SenderID 05890FC7 and 4BS telegram, please define it.
2024.12.26 14:13:13 2: autocreate: define EnO_05890FC7 EnOcean 05890FC7 EnOcean:1:A5:09A62B2E:05890FC7:80:03FFFFFFFF2E00
2024.12.26 14:13:13 2: EnOcean define EnO_05890FC7 EnOcean 05890FC7 EnOcean:1:A5:09A62B2E:05890FC7:80:03FFFFFFFF2E00
2024.12.26 14:13:13 2: EnOcean define FileLog_EnO_05890FC7 FileLog ./log/EnO_05890FC7-%Y.log EnO_05890FC7
2024.12.26 14:13:13 2: EnOcean EnO_05890FC7 4BS teach-in is missing
2024.12.26 14:13:15 5: TCM TCM_ESP3_0 received ESP: 55000A0701EBA509A62B2E05890FC78003FFFFFFFF300068
2024.12.26 14:13:15 5: TCM_ESP3_0: dispatch EnOcean:1:A5:09A62B2E:05890FC7:80:03FFFFFFFF3000
2024.12.26 14:13:15 5: EnOcean received via TCM_ESP3_0: EnOcean:1:A5:09A62B2E:05890FC7:80:03FFFFFFFF3000
Das Gerät ist danach praktisch unbrauchbar - wenn ich nun aus dem Beispiel gleicher Geräte (Produktionsdatum einzelne Monate auseinander) die Attribute einkopiere, dann empfange ich Nachrichten, kann auch senden, doch die Geräte gehen nach einer Weile in eine Art Tiefschlaf (auch bei WakeUpCycle 600). Was muss ich tun, um ein vollständiges/fehlerhaftes Teachin zu erreichen (in der Hoffnung, dass die Geräte dann ordentlich laufen)

Hat jemand einen Tipp/best practice für das weitere Vorgehen?

Christian
PI 2B+/5 Raspbian 12, Perl 5.36.0, FHEM 6.3: 295 Module in ConfigDB: Steuerung Heizkessel, FBH, Solarthermie, kontr. Lüftung mit WRG. Smarthome u.a. HMCUL, 1-Wire (FT232RL ; DS2480B), EnOcean (TCM EPS3), MQTT2. DOIF, PID20, Threshold, OWX; Micropelt IRTV, Volkszähler, SolarForecast; MariaDB

Flachzange

Hi Christian,

ich nehme an, Du hast bereits MVA-005s und bist mit dem Prozedere vertraut? Bist Du sicher, dass sich Dein Log-Auszug auf den Einlern-Prozess des MVA-005 bezieht? Ggf. auch nochmal kurz hier Dein Vorgehen schildern. Der Antrieb gibt Dir über die LEDs ja auch eine Rückmeldung, ob der Vorgang erfolgreich war.

Im Zweifel MVA-005 nochmal resetten, Device löschen und FHEM auch noch einmal durchstarten und nochmal von vorne beginnen.


Du musst in jedem Fall ein sauberes Pairing hinbekommen, sonst sind die Geräte nicht steuerbar bzw. gehen in den Tiefschlaf.

Indizien, dass es geklappt hat:
- 4BS teach-in accepted
- Du erhältst in den ersten 30 Minuten alle 2 Minuten ein Update wenn ich das jetzt auf die schnelle beim MVA005 richtig gesehen habe
- Änderungen am Setpoint sollten bei der nächsten Kommunikation übernommen werden

Ich habe mit einem MVA004 bei mir gerade mal rumgspielt. Bei mir brauchte es nach dem Rückfahren in die Montageposition ein einlernbereites TCM und dann war das Paring wieder da. Aber auch nur wenn das Device noch nicht da ist oder in subdef keine ID steht.

Damu

Hallo

Sind die Geräte Neu oder oder hast Du die gebraucht gekauft.
Wenn Sie Neu sind sollten die Akkus ok sein.
Wenn gebraucht kann es natürlich sein das der Akku zu wenig Strom abgibt.
Für das Anlernen und Justieren der Endlagen sollte der Akku schon ok sein.



cwagner

#3
Also, das vorgehen habe ich glaube ich intus und sicherheithsalber auch das User manuel noch einmal zur Hand genommen. Tstsächlich melden sich die Geräte, wenn ich Ihnen alle fehlenden Attribute, vor allem den richtigen EEP und subType gegegeben habe auch anfangs alle 120 Sekunden, doch danach verschwinden sie vom Radar bzw. schalten auf endlos lange Sendezeiten (3600 Sekunden). die Akkus zeigen die richtige Spannung bzw. sind auf 3,3 V nachgeladen. (Ladeschluss 3,75 eingehalten bei Abfall auf <10 mA). Tatsächlich verhalten sich alle drei Geräte aus demselben Gebrauchtkauf identisch, sodass ich den Verdacht habe, dass sie mit einem Commissionierungssystem auf irgendwelche Links "geprägt" sind. Dazu habe ich vom Verkäufer keine Angaben erhalten.

Noch eine Beobachtung: Durch kurzes aktivieren kann ich das Gerät zum sofortigen Übermitteln der Daten bringen. Der wakeUpCycle springt auf 120 Sekunden, der Setpoint wird neu berechnet, der Status selbst des Window-Controls wechselt. Auch spiegelt sich die manuelle Verstellung über das Drehrad um bis zu ±5 K sofort im Fhem-Device. 004 und 005 unterscheiden sich ja im EEP. Und ich habe ja einige funktonierende Muster, aus denen ich mir ja die Attribute zusammengekramt habe.

Hmh, da habe ich womöglich in den Eimer gegriffen...

Christian
PI 2B+/5 Raspbian 12, Perl 5.36.0, FHEM 6.3: 295 Module in ConfigDB: Steuerung Heizkessel, FBH, Solarthermie, kontr. Lüftung mit WRG. Smarthome u.a. HMCUL, 1-Wire (FT232RL ; DS2480B), EnOcean (TCM EPS3), MQTT2. DOIF, PID20, Threshold, OWX; Micropelt IRTV, Volkszähler, SolarForecast; MariaDB

klaus.schauer

Zitat von: cwagner am 26 Dezember 2024, 23:04:18Also, das vorgehen habe ich glaube ich intus und sicherheithsalber auch das User manuel noch einmal zur Hand genommen. Tstsächlich melden sich die Geräte, wenn ich Ihnen alle fehlenden Attribute, vor allem den richtigen EEP und subType gegegeben habe auch anfangs alle 120 Sekunden, doch danach verschwinden sie vom Radar bzw. schalten auf endlos lange Sendezeiten (3600 Sekunden).
Bidirektionale Aktoren wie diese erhalten beim erfolgreichen teach-in automatisch alle für den Betrieb notwendige Attribute insbesondere den subtype und die Sende- und Empfangs-IDs. Manuell kann und muss man für die Grundeinstellung gar nichts mehr machen!

Falls die Anmeldung vom Fhem am Aktor nicht erfolgreich war, so geht der Aktor nach einer gewissen Zeit in den Ruhemodus.

Falls die Geräte tatsächlich per remote management parametrisiert worden sind, so kann man das im EnOcean-Modul auch auslesen und setzen. Das ist aber was für Insider! Die Kommandos sind in der commandref beschrieben. Vielleicht findet man dazu in der Gebrauchsanleitung eine Aufstellung über die herstellerspezifischen Parameter oder eine Beschreibung für einen Werksreset.

cwagner

Vielen Dank, Klaus Schauer, für die Bestätigung meines Verdachtes.

Ich hoffe noch auf Informationen zum Werksreset, denn in den mir zugänglichen Quellen fand ich bisher nur Angaben zu einem Reset, der aber vor allem Linktables u.ä. nicht zurücksetzt.

Christian
PI 2B+/5 Raspbian 12, Perl 5.36.0, FHEM 6.3: 295 Module in ConfigDB: Steuerung Heizkessel, FBH, Solarthermie, kontr. Lüftung mit WRG. Smarthome u.a. HMCUL, 1-Wire (FT232RL ; DS2480B), EnOcean (TCM EPS3), MQTT2. DOIF, PID20, Threshold, OWX; Micropelt IRTV, Volkszähler, SolarForecast; MariaDB

IPWF

Die ReMan/ReCom-Befehle für den Reset auf Werkseinstellungen sowie die Voraussetzungen dafür sind im Handbuch beschrieben, das auf der Webseite des Herstellers zum Download steht.
FHEM auf Hardkernel ODROID-N2+ mit Ubuntu 22.04.5 LTS
Funkschnittstelle EnOcean

cwagner

Ja, richtig, die Doku habe ich auch berücksichtigt. Leider habe ich auch nach einem Reset immer noch die Schwierigkeiten. Auch nach einem Hardreset auf Auslieferungszustand gelingt kein vollständiges Teach-in und die Dinger ignorieren das Attribut, dass Ihnen vorgibt, eine externe Temperatur-Referenz zu berücksichtigen (measurementTypeSelect feed) und das Reading roomtemp statt feedtemp wird gesendet (subType hvac.06)
PI 2B+/5 Raspbian 12, Perl 5.36.0, FHEM 6.3: 295 Module in ConfigDB: Steuerung Heizkessel, FBH, Solarthermie, kontr. Lüftung mit WRG. Smarthome u.a. HMCUL, 1-Wire (FT232RL ; DS2480B), EnOcean (TCM EPS3), MQTT2. DOIF, PID20, Threshold, OWX; Micropelt IRTV, Volkszähler, SolarForecast; MariaDB

IPWF

Zitat von: cwagner am 28 Dezember 2024, 07:59:55... und die Dinger ignorieren das Attribut, dass Ihnen vorgibt, eine externe Temperatur-Referenz zu berücksichtigen (measurementTypeSelect feed) und das Reading roomtemp statt feedtemp wird gesendet (subType hvac.06)
Wenn Du measurementTypeSelect = feed gewählt hast, wird natürlich kein externer Sensor berücksichtigt.
Wenn measurementTypeSelect = room ist, wird der externe Sensor berücksichtigt; falls dieser jedoch einen Signalausfall hat oder das Reading "temperature" fehlt oder anders heißt, geht der MVA-005 in den Tiefschlaf, bis der Sensor wieder korrekt liefert. Welchen Sensor benutzt Du denn ?
FHEM auf Hardkernel ODROID-N2+ mit Ubuntu 22.04.5 LTS
Funkschnittstelle EnOcean

Damu

Kannst Du bitte mal angeben wie deine Einstellungen am TCM sind.


Wie lernst du an?
"Drehen bis Anschlag Links ODER Rechts,
5 s halten bis 1x grüne LED,
dann zum entgegengesetzt en Anschlag drehen und unmittelbar wieder loslassen."

IPWF

Zitat von: IPWF am 28 Dezember 2024, 18:01:24Wenn Du measurementTypeSelect = feed gewählt hast, wird natürlich kein externer Sensor berücksichtigt.
Sorry, das war Quatsch. Auch bei der Einstellung feed kann der externe Sensor verwendet werden. Die genannten Voraussetzungen müssen aber in jedem Fall gewährt sein.
FHEM auf Hardkernel ODROID-N2+ mit Ubuntu 22.04.5 LTS
Funkschnittstelle EnOcean

Damu

Ein externer Sensor wird mit attr temperatureRefDev "Sensor" hinzugefügt.
Da muss nur ein Sensor mit Temp Reading angegeben werden.

Aber zuerst sollte das Teil angelernt sein, das scheint aber hier wohl nicht zu gehen.


cwagner

Also, diesen Thread möchte ich hier gerne abschließen, weil ich offenbar bei den gebraucht gekauften 3 Geräten an welche geraten bin, die ich nicht in den Griff bekomme. Ich habe inzwischen Softreset (Drehregler nach links oder rechts 10 Sekunden, nach 5 Sekunden erstes und nach weiteren 5 Sekunden zweites grünes Blinken, Prüffahrt unmontiert) probiert, sowie einen Hardreset nach Herstellerangaben, Nachladen des Akkus und vieles mehr. Hier muss ich wohl aufgeben.

Zu den Fragen (mein Stick lernt andere Geräte problemlos an, auch Wiederkehrer (gemäß Empfehlung von Modulautor Klaus.Schauer grundsätzlich nach Löschen und Neustart von FHEM):
defmod TCM_ESP3_0 TCM ESP3 /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A90551F8-if00-port0@57600
attr TCM_ESP3_0 .baseIDSaved XXXXXXXX
attr TCM_ESP3_0 .chipIDSaved ********
attr TCM_ESP3_0 learningDev all
attr TCM_ESP3_0 room EnOcean
attr TCM_ESP3_0 sendInterval 15

Das Anlernen mache ich so:
1. Softreset, wie oben beschrieben
2. Stick über set TCM_ESP3_0 teach 600 in den Anlernmodus versetzen
3. Drehregler nach links oder rechts für 5 Sekunden halten bis grüne Lampe einmal blinkte
4. Aktor nun montieren
5. Drehregler kurz nach links oder rechts anschlagen, es folgt die Referenzfahrt und ein grünes Blinken

Wenn ich ein Funktelegramm auslösen will, mache ich eine Verstellung nach links und nach einer kleinen Pause nach rechts (oder umgekehrt). Dann sehe ich in FHEM sofort das Aktualisieren der Readings.


Christian



PI 2B+/5 Raspbian 12, Perl 5.36.0, FHEM 6.3: 295 Module in ConfigDB: Steuerung Heizkessel, FBH, Solarthermie, kontr. Lüftung mit WRG. Smarthome u.a. HMCUL, 1-Wire (FT232RL ; DS2480B), EnOcean (TCM EPS3), MQTT2. DOIF, PID20, Threshold, OWX; Micropelt IRTV, Volkszähler, SolarForecast; MariaDB

Damu

baseID ist schon eine gesetzt?

Mit den MVA005 und MVA009 hatte ich auch am meisten Probleme.
Jetzt gehen sie aber.
Hatte einen MVA004 der ging auch nicht ohne Reset.
Es hatte auch welche bei denen die Antenne nicht gut war.
Beim Abisolieren wurden da dei Drähte angeschnitten.
Micropelt war hat mir da ein Stück Draht gesendet, war ein Fehler in der Produktion.

cwagner

Ja, die Base-ID ist gesetzt, hatte ich nur ausge-ixt.
Die manchmal wackeligen Antennen sind mir auch schon aufgefallen. Aber tatsächlich habe ich ja Funkkontakt, FHEM und Aktor reden ja miteinander, wenn ich das unvollständige Teachin durch setzen aller fehlenden Attribute wie EEP, subDef, subtype vervollständige. Allerdings gibt es eine Reihe von Eigenschaften, die sich mit einem solchen unvollständigen Teachin nicht ordentlich setzen lassen. Aufgefalen war es mir zuerst bei der feedTemp und dann bei den reorteten wakeUpcyclen. Anderserseits werden Temperaturänderungen über das Drehrad postwenden gemeldet und zwar stimmig. Mir gelingt es nicht, die Aktoren davon abzubringen, ausschließlich mit ihre eigenen (in meinem Fall nicht geeigneten) eigenen Temperatursensor zu arbeiten.
PI 2B+/5 Raspbian 12, Perl 5.36.0, FHEM 6.3: 295 Module in ConfigDB: Steuerung Heizkessel, FBH, Solarthermie, kontr. Lüftung mit WRG. Smarthome u.a. HMCUL, 1-Wire (FT232RL ; DS2480B), EnOcean (TCM EPS3), MQTT2. DOIF, PID20, Threshold, OWX; Micropelt IRTV, Volkszähler, SolarForecast; MariaDB