MD15 Subtype wird falsch gesetzt

[Schorsch M.]

Servus allesammt :)

Ich hab ein kleines Problem mit meinem MD15-FtL-HE.
Wenn ich ihn mit Fhem paire funktioniert alles soweit wunderbar und er wird auf der Weboberfläsche als
subType MD15 erkannt und ich kann mit ihm problemlos kommunizieren.
Nur wird der subType in der fhem.cfg als sensor angelegt.
Starte ich Fhem neu, hat dies zu Folge das Fhem nicht mehr mit dem MD15 kommunizieren kann.

Die einzige Lösung die bisher funktioniert, ist dass ich nach dem Pairing-Vorgang den subType manuell oder über den Set-Befehl in der fhem.cfg anlege.

Ich habe dies mit Fhem in den Version 5.2 und 5.3 getestet.

Hat jemand dies ebenfalls bereits beobachtet oder vll sogar eine Lösung dafür, dass der subType des MD15 beim Pairing korrekt in der fhem.cfg angelegt wird?

Gruß Georg

[klaus.schauer]

Ich nehme an, dass der Fehler auch in der aktuellen Version 2897 des Moduls 10_EnOcean besteht. Das MD15 Profil habe ich unverändert gelassen.

Was steht im Attribut subType

vor dem teach-in, also nachdem der MD15 ein normales Datentelegramm gesendet hat ... wahrscheinlich sensor
nach dem bidirectionalen teach-in ... hoffentlich MD15
nach einem save-Befehl

Wird das Reading "teach-in" angezeigt ... wahrscheinlich mit "EEP A5-20-01 Manufacturer: Thermokon"?

Wurde der Heizungsregler über das bidirektionale Pairing eingerichtet? Das wäre aus meiner Sicht der einzige Unterschied zum automatischen Anlernen der anderen Sensoren. Z. B. beim Anlernen des Sensors Eltako FIFT63AP steht das Attribute subType zuerst auf "sensor" und nach dem teach-in Telegramm auf "tempHumiSensor.02". Weiterhin gibt es ein Reading teach-in mit "EEP A5-04-02 Manufacturer: Eltako".

[krikan]

Hallo!

Bei mir steht vor dem teach-in
subType: Sensor

nach dem teach-in ist
subType: MD15

das Reading teach-in:EEP A5-20-01 Manufacturer: Kieback + Peter

Muss ich nicht nach jedem Anlegen/teach-in Save anklicken, damit es in fhem.cfg gespeichert wird? Teilweise taucht auch global save auf!?

Gruß, Christian

[klaus.schauer]

Hallo!

Bei mir steht vor dem teach-in
subType: Sensor

nach dem teach-in ist
subType: MD15

das Reading teach-in:EEP A5-20-01 Manufacturer: Kieback + Peter

Muss ich nicht nach jedem Anlegen/teach-in Save anklicken, damit es in fhem.cfg gespeichert wird? Teilweise taucht auch global save auf!?

Gruß, Christian

Ich kann es selbst leider nicht probieren, aber eigentlich sollte der Ablauf so sein:

- ggf. alte devices-Anträge löschen, auch readings
- bidirektionales A5 Teach-In starten (siehe commandref): set <name> pairForSec <t/s>
- Lernprozedur am MD15 starten
- device sollte in Fhem angelegt und der MD15 steuerbar sein
- danach ggf. per save speichern
- fertig, alles gut

[krikan]

- ggf. alte devices-Anträge löschen, auch readings
- bidirektionales A5 Teach-In starten (siehe commandref): set <name> pairForSec <t/s>
- Lernprozedur am MD15 starten
- device sollte in Fhem angelegt und der MD15 steuerbar sein
- danach ggf. per save speichern
- fertig, alles gut

So habe ich das gemacht und es schaut auch alles gut aus. Jedoch kann ich den MD15 danach immer noch nicht mit FHEM steuern. Das war auch schon vor Deinem Umbau von 10_EnOcean.pm so. Ich bekomme das Ding mit FHEM nicht in Gang, zu d... dazu. In den Readings steht DestinationID=FFFFFFFF trotz angeblich erfolgreichem teach-in. Müsste dort nicht was anderes stehen?

Georg hat meiner Meinung nach nur nicht save angeklickt, was zu wohl zu seinen Problemen führt. Mich wundert nur, dass ich bei meinen Tests teilweise beim Anlegen von Senoren Meldungen mit Global:save o.ä. erhielt, die ich als automatisches speichern von fhem.cfg interpretiert hatte und gerade natürlich nicht reproduziert bekomme. Den Thread der evtl. weiterhelfen könnte "statefile und eigene device settings sichern" übersteigt mein FHEM-Knowhow komplett.....

[klaus.schauer]

- ggf. alte devices-Anträge löschen, auch readings
- bidirektionales A5 Teach-In starten (siehe commandref): set <name> pairForSec <t/s>
- Lernprozedur am MD15 starten
- device sollte in Fhem angelegt und der MD15 steuerbar sein
- danach ggf. per save speichern
- fertig, alles gut

So habe ich das gemacht und es schaut auch alles gut aus. Jedoch kann ich den MD15 danach immer noch nicht mit FHEM steuern. Das war auch schon vor Deinem Umbau von 10_EnOcean.pm so. Ich bekomme das Ding mit FHEM nicht in Gang, zu d... dazu. In den Readings steht DestinationID=FFFFFFFF trotz angeblich erfolgreichem teach-in. Müsste dort nicht was anderes stehen?

Georg hat meiner Meinung nach nur nicht save angeklickt, was zu wohl zu seinen Problemen führt. Mich wundert nur, dass ich bei meinen Tests teilweise beim Anlegen von Senoren Meldungen mit Global:save o.ä. erhielt, die ich als automatisches speichern von fhem.cfg interpretiert hatte und gerade natürlich nicht reproduziert bekomme. Den Thread der evtl. weiterhelfen könnte "statefile und eigene device settings sichern" übersteigt mein FHEM-Knowhow komplett.....

Schade, ich hatte den Eindruck, dass das Problem mit dem Wiederauffinden des Befehls set <name> pairForSec <t/s> gelöst sei. War da nicht jemand, der es damit jetzt ans Laufen gebracht hat?

[krikan]

War da nicht jemand, der es damit jetzt ans Laufen gebracht hat?

Ja, wenn ich es richtig sehe der Threaderöffner Georg: Link

[Schorsch M.]

Georg hat meiner Meinung nach nur nicht save angeklickt, was zu wohl zu seinen Problemen führt.

Save habe ich gedrück, hatte nur vergessen es zu schreiben.
Wie erwähnt wird MD15 ja als subType gesetzt sobald ich in der Weboberfläsche das Attribut setze.
Eben nur nicht wenn ich ihn "nur" normal paire.

Was mir nun noch aufgefallen ist, ist das vor dem Pairing Prozess EnOcean_Define($$) aufgerufen wird.
Hier wird bereits der subType als sensor gesetzt. Hab mir einfach mal eine Trace-Ausgabe reingebaut und die Variable zur Kontrolle im fhem_Logfile ausgegeben.
Beim Pairing wird wieder das Attribut für den subType gesetzt. Aber irgendwie wird dieser nicht in der fhem.cfg überschrieben.

War da nicht jemand, der es damit jetzt ans Laufen gebracht hat?

Ja, wenn ich es richtig sehe der Threaderöffner Georg: Link

Jupp, mein MD15 läuft einwandfrei :)
Wie ich vorgegangen bin hab ich in dem andern Thread beschrieben. (siehe link oben)
Ich hab auch eins zwei Änderungen eingebaut. So kann ich jetzt neben der desired-temp auch die measured-temp selber setzten. Bzw. den zurückgelieferten Wert eines Sensors nutzen.
Auch hab ich das bei mir vorliegende Problem gelöst, dass Fhem dem MD15 keine Antwort gegeben hat, solange noch kein Kommando abgesetzt wurde.
Jetzt sendet Fhem erst einmal ein default-Wert für die desired-temp und nutzt die vom MD15 zurückgelieferte measured-temp bis eine eigene gesetzt wird.

[krikan]

Hallo Georg!

Beim Pairing wird wieder das Attribut für den subType gesetzt. Aber irgendwie wird dieser nicht in der fhem.cfg überschrieben.

Dein Problem mit dem subType kann ich hier mit meinem MD15 nicht nachvollziehen bzw. verstehe ich noch nicht. Beim Bidi-Pairing wird der subType bei mir auf MD15 gesetzt und bleibt auch nach dem Neustart von FHEM immer erhalten. Habe das mehrfach ausprobiert. ABER ich kann den MD15 nie steuern.

Jupp, mein MD15 läuft einwandfrei :)
Wie ich vorgegangen bin hab ich in dem andern Thread beschrieben. (siehe link oben)

Neid! Ich habe mich an Deine Erläuterungen gehalten; die doch auch mit Klaus Angaben von oben deckungsgleich sind. Erfolgreiches Pairing wird zwar durch den MD15 signalisiert, aber ich kann trotzdem keine Steuerung erreichen. Nur die Sensorwerte kommen in FHEM an. Die Detailseite vom MD15 habe ich mal als Screenshot angehängt. Vielleicht fällt Dir was zu meinem Problem auf. Du hattest im anderen besagten Thread mal was zur DestinationID geschrieben; müsste demnach nicht bei mir etwas anderes als FFFFFFFF stehen? Anscheinend hast Du auch den Code für den MD15 in 10_EnOcean.pm geändert. Funktioniert deshalb Dein MD15 und meiner nicht?

Gruß, Christian

[klaus.schauer]

Die Programmteile für MD15 sind nicht verändert worden. Schließlich war die Funktionalität bereits vollständig und in Ordnung ... dachte ich.

Ich werde aber sicherheitshalber die MD15 Programmteile zwischen den Versionen vergleichen.

Eine andere Idee: Welche SenderIDs werden für andere Geräte als den MD15 verwendet? Beim bidirektionalen Pairing wird immer die BaseID genutzt. Sicherheitshalber würde ich deshalb mit dieser SenderID nicht auch andere Geräte steuern.

[krikan]

Hallo Klaus,

Die Programmteile für MD15 sind nicht verändert worden.

Wenn Du meinen Beitrag von heute morgen meinst:
Meine Äußerung zu den Codeänderungen bezog sich auf Georg. Das ist nämlich derzeit meine letzte Hoffnung. Ich hatte meine Probleme mit dem MD15 immer auf Codeprobleme zurückgeführt, da auch Rudi nach meiner Erinnerung das "Ding" nicht zum Laufen gebracht hat.

Eine andere Idee: Welche SenderIDs werden für andere Geräte als den MD15 verwendet? Beim bidirektionalen Pairing wird immer die BaseID genutzt. Sicherheitshalber würde ich deshalb mit dieser SenderID nicht auch andere Geräte steuern.

Das verstehe ich nicht. Ich nutze doch immer BaseID+x zum "normalen" Anlernen. Beim MD15 kann ich doch nichts vorgeben!?

Danke und Gruß, Christian

[Schorsch M.]

Hallo Christian,

Das verstehe ich nicht. Ich nutze doch immer BaseID+x zum "normalen" Anlernen. Beim MD15 kann ich doch nichts vorgeben!?

Ich nutze auch einfach die Base-ID meines TCM310 USB-Sticks. Schiefgehen kann da nichts mit anderen Geräten,
da Fhem im Fall des MD15 an eine bestimmte Ziel-ID sendet.

Die Detailseite vom MD15 habe ich mal als Screenshot angehängt. Vielleicht fällt Dir was zu meinem Problem auf. Du hattest im anderen besagten Thread mal was zur DestinationID geschrieben; müsste demnach nicht bei mir etwas anderes als FFFFFFFF stehen?

Mit der Destination-ID ist glaube ich in dem Fall die Ziel-ID gemeint an die der MD15 gesendet hat. Schließlich sind alle anderen Informationen in dem Fenster auch Daten aus dem vom TCM weitergeleiteten seriellen Telegramm. Bei mir steht auch FFFFFFF.

Anscheinend hast Du auch den Code für den MD15 in 10_EnOcean.pm geändert. Funktioniert deshalb Dein MD15 und meiner nicht?

Nein, die Codeänderungen habe ich erst gemacht nachdem ich den MD15 zum laufen gebracht habe.

Christian, was für einen Empfänger nutzt du denn für EnOcean?
TCM3er oder TCM2er Serie?
Vll. liegt dein Problem ja ganz woanders - ist jetzt erst mal nur so eine Idee.

[klaus.schauer]

Hallo Klaus,

Die Programmteile für MD15 sind nicht verändert worden.

Wenn Du meinen Beitrag von heute morgen meinst:
Meine Äußerung zu den Codeänderungen bezog sich auf Georg. Das ist nämlich derzeit meine letzte Hoffnung. Ich hatte meine Probleme mit dem MD15 immer auf Codeprobleme zurückgeführt, da auch Rudi nach meiner Erinnerung das "Ding" nicht zum Laufen gebracht hat.

Eine andere Idee: Welche SenderIDs werden für andere Geräte als den MD15 verwendet? Beim bidirektionalen Pairing wird immer die BaseID genutzt. Sicherheitshalber würde ich deshalb mit dieser SenderID nicht auch andere Geräte steuern.

Das verstehe ich nicht. Ich nutze doch immer BaseID+x zum "normalen" Anlernen. Beim MD15 kann ich doch nichts vorgeben!?

Danke und Gruß, Christian

Ja beim bidirektionalen Pairing wird immer die BaseID verwendet. Ich wollte klären, ob beim "nomalen" Anlernen eben nicht auch BaseID+0 verwendet wird. Vielleicht überschneidet sich da was.

Ich habe mal den Programmcode zu MD15 V 2076 2012-11-04 mit der aktuellen verglichen. Ich kann keinen Unterschied erkennen. Zur Sicherheit könnte man mal die alte Version einsetzen oder in einer funktionierenden Umgebung die neue testen.

Wenn ich die Programmierung für den MD15 richtig verstanden habe, wird ein Sendebefehl in dem Reading CMD nach der Eingabe gespeichert und sobald sich der MD15 wieder mit einem Datentelegramm meldet ausgelesen und gesendet. Also müsste CMD temporär auch in der WEB-Oberfläche zu sehen sein. Vielleicht kommen wir dem Fehler so auf die Schliche.

Ausserdem gibt es noch einen Befehl "initialize" der nicht in der commandref steht. Vielleicht findet sich jemand, der die Bedeutung kennt. Könnte gut sein, dass der eigentliche teach-in-Prozess etwas trickreich ist und genauer beschrieben werden müsste.

[Schorsch M.]

Wenn ich die Programmierung für den MD15 richtig verstanden habe, wird ein Sendebefehl in dem Reading CMD nach der Eingabe gespeichert und sobald sich der MD15 wieder mit einem Datentelegramm meldet ausgelesen und gesendet. Also müsste CMD temporär auch in der WEB-Oberfläche zu sehen sein. Vielleicht kommen wir dem Fehler so auf die Schliche.

Hallo Klaus, der MD15 meldet sich alle 10min zurück. Fhem hat dann ein 1Sekunden Fenster um zu antworten und das letzte gesetzte CMD zu senden. Dieses wird, wie du bereits gesagt hast, nach seiner Eingabe bereits temporär in der WEB-Oberfläche angezeigt. z.B.    STATE | desired-temp
Solange noch kein CMD gesetzt wurde, antwortet Fhem dem MD15 auch nicht.

Christian, du solltest dir mal in die Methoden EnOcean_MD15Cmd($$$), EnOcean_A5Cmd($$$) und EnOcean_Parse($$) (beim Pairing und bei elsif($st eq "MD15")) überall Trace-Ausgaben einbauen und das ganze im Log-File beobachten. So müsstest du ja rausbekommen wo es hängt.
Falls du nicht weißt wie das geht - hier ein Beispiel.

$st = $EnO_subType{$st} if($EnO_subType{$st});
$attr{$name}{subType} = $st;
Log 2, "Attribut:  $attr";   #Schreibt Attribut: und gibt die Variable $attr aus im Log-File.
if("$fn.$tp" eq "20.01" && $iohash->{pair})
.  
.
.
Kleister dir einfach alles voll damit. ;)

[Schorsch M.]

Ausserdem gibt es noch einen Befehl "initialize" der nicht in der commandref steht. Vielleicht findet sich jemand, der die Bedeutung kennt. Könnte gut sein, dass der eigentliche teach-in-Prozess etwas trickreich ist und genauer beschrieben werden müsste.

Hallo Klaus, das mit dem "initialize" hab ich auch noch nicht so ganz verstanden was das bringt.
So wie ich das bis jetzt beobachtet habe und wie der Code aussieht, wird einfach nur das CMD gelöscht und vorher noch einmal das letzte CMD gesendet. Was zur folge hat das fhem dem MD15 keine Antwort mehr gibt und dieser nach einer Stunde in den self-controlled mode geht.

Bei mir wurde, nach dem ich das CMD initialize ausgeführt habe, noch einmal mein davor letztes gesetztes CMD (92 57 04 00) und
anschließend die Daten 00 00 64 00 gesendet. (0x64 => 01100100) Dies entspricht folgenden Einstellungen.

1 Set point selection DB_3 0b1 temperature set point gesetzt
1Lift set, only active in service mode
1Valve open, only active in service mode


   if($msg) {
      select(undef, undef, undef, 0.2);
      EnOcean_A5Cmd($hash, $msg, "00000000");
      if($cmd eq "initialize") {
        delete($defs{$name}{READINGS}{CMD});
        delete($defs{$name}{READINGS}{$cmd});
      }

Danach gibt Fhem dem MD15 keine antwort mehr.