hvac.01 ohne aktive Regelung möglich? (EEP A5-20-01 / MVA 004)

[Flachzange]

Hallo zusammen,

ich habe ein Dutzend Micropelt MVA 004 (EEP A5-20-01) Stellantriebe, mit denen ich auch sehr zufrieden bin. Bisher hatte ich die Regelung über FHEM laufen (mit Reference Devices und PID Controller). Nun werden neuerdings einige der Stellantriebe außerhalb von FHEM über einen externen Controller gesteuert. Das funktioniert auch gut so weit.

FHEM meint jedoch weiterhin auf Nachrichten dieser MVA 004 reagieren zu müssen und sendet immer sofort eine Response. Dem MVA 004 ist das egal, weil er ja mittlerweile mit dem externen Controller gekoppelt ist. In der Konsequenz bedeutet dies jedoch, dass FHEM die Readings des devices mit Werten überschreibt, die nicht vom Stellantrieb kommen, sondern wo FHEM meint, dass es die richtigen sind (insbesondere SetpointTemp).

Mein Wunsch wäre, dass ich den Stellantrieb als eine Art read-only device weiterhin in FHEM sehe, um Auswertungen über Sollwerte etc. zu machen. Was ich schon versucht habe:

• alle reference devices gelöscht
• attr pidCtrl off
• subDef gelöscht
• device gelöscht und versucht ohne teachIn über autocreate neuzuerstellen => autocreate reagiert hier nur auf teachin
• manuell die Readings setpointTemp und setpointTempSet gelöscht => FHEM erstellt Reading neu mit einem Wert, wo nicht klar ist, wo der herkommt. Der MVA 004 übermittelt diesen nicht

Wenn jemand eine Idee hat, wie ich das realisieren kann, gerne einen Denkanstoß geben.

Beispiel Kommunikation:

2021.03.28 12:26:20 4: EnOcean Stellantrieb_Schlafzimmer received from IODev: TCM_ESP3_0 PacketType: 1 RORG: A5 DATA: 00206C08 SenderID: 0514D8B4 STATUS: 01
2021.03.28 12:26:20 5: EnOcean Stellantrieb_Schlafzimmer EnOcean_parse SPT: 20.0 SPTS: 20.0
2021.03.28 12:26:20 4: EnOcean Stellantrieb_Schlafzimmer sent PacketType: 1 RORG: A5 DATA: 7F8C0408 SenderID: 0514D8B4 STATUS: 00 ODATA: 030514D8B4FF00

Warum das Modul hier SPT: 20.0 SPTS: 20.0 ableitet ist mir nicht klar. Der Stellantrieb sendet keine SPT, sondern nur SP. Ich würde auch erwarten, dass das zweite Byte in der Response 0 ist, wenn kein temperatureRefDevice gesetzt ist. Die SenderID in der Response im obigen Beispiel ist Blödsinn, weil ich subDef gelöscht hatte.

Danke und Gruß
Chris

[klaus.schauer]

Der Blödsinn passiert eben, wenn man ein bidirektionales Profil zweckentfremdet. Wäre selbst nicht auf diese Idee gekommen. Mich wundert deshalb auch nicht, dass die Daten nicht passen. Z. B. ist gewollt dass DEF gesendet wird, falls subDef fehlt. Ich würde mal das Attribut disable setzen; könnte helfen. Ansonsten geht's mit dem RAW-Profil natürlich immer.

[Flachzange]

Hallo Klaus,

danke für die Rückmeldung!

Der Blödsinn passiert eben, wenn man ein bidirektionales Profil zweckentfremdet. Wäre selbst nicht auf diese Idee gekommen. Mich wundert deshalb auch nicht, dass die Daten nicht passen. Z. B. ist gewollt dass DEF gesendet wird, falls subDef fehlt.

Vielleicht hatte ich mich da ungünstig ausgedrückt. Mir war schon klar, warum die SenderID so ist, wie sie ist. Ich wollte eigentlich nur darauf hinweisen, dass ich subdef testweise entfernt hatte. Ob man das jetzt "zweckentfremden" nennt, ist wohl Ansichtssache bzw. ist es das wohl im Sinne der EnOcean Spec, wenn Du es sagst. Ich bin erstmal grundsätzlich davon ausgegangen, dass ich alle Telegramme von devices mitlesen können muss ohne dass man gleich ein RAW-Profil hat. Dass ein Profil zwangsweise bidrektional sein kann, war mir nicht bekannt.

Ich würde mal das Attribut disable setzen; könnte helfen. Ansonsten geht's mit dem RAW-Profil natürlich immer.

disable ändert an der Bidirektionalität auch nichts.

Aber danke für die Aufklärung. Dann brauche nicht weiter suchen.

Gruß
Chris