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
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".
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
Zitat von: krikan schrieb am Mi, 13 März 2013 20:32Hallo!
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
Zitat- 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.....
Zitat von: krikan schrieb am Mi, 13 März 2013 22:09Zitat- 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?
ZitatWar da nicht jemand, der es damit jetzt ans Laufen gebracht hat?
Ja, wenn ich es richtig sehe der Threaderöffner Georg: Link (http://forum.fhem.de/index.php?topic=11333.msg66211#msg66211)
Zitat von: krikan schrieb am Mi, 13 März 2013 22:09Georg 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.
Zitat von: krikan schrieb am Mi, 13 März 2013 22:27ZitatWar 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.
Hallo Georg!
ZitatBeim 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.
ZitatJupp, 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
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.
Hallo Klaus,
ZitatDie 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.
ZitatEine 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
Hallo Christian,
Zitat von: krikan schrieb am Do, 14 März 2013 07:35Das 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.
Zitat von: krikan schrieb am Do, 14 März 2013 06:23Die 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.
Zitat von: krikan schrieb am Do, 14 März 2013 06:23Anscheinend 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.
Zitat von: krikan schrieb am Do, 14 März 2013 07:35Hallo Klaus,
ZitatDie 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.
ZitatEine 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.
Zitat von: klaus.schauer schrieb am Do, 14 März 2013 09:49Wenn 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. ;)
Zitat von: klaus.schauer schrieb am Do, 14 März 2013 09:49Ausserdem 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 => 0
1100
100) 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.
Zitat von: Schorsch M. schrieb am Do, 14 März 2013 10:57Zitat von: klaus.schauer schrieb am Do, 14 März 2013 09:49Ausserdem 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.
Kommt die Kommunikation später wieder zustande, sobald ich in Fhem einen neuen Befehl setze? Dann wäre der Befehl als "reset" vielleicht sinnvoll.
Zitat von: klaus.schauer schrieb am Do, 14 März 2013 12:31Zitat von: Schorsch M. schrieb am Do, 14 März 2013 10:57Zitat von: klaus.schauer schrieb am Do, 14 März 2013 09:49Ausserdem 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.
Kommt die Kommunikation später wieder zustande, sobald ich in Fhem einen neuen Befehl setze? Dann wäre der Befehl als "reset" vielleicht sinnvoll.
Hi Klaus, ich werde das heute noch mal ausprobieren. Denke aber, dass Fhem wieder antworten sollte sobald ein CMD gesetzt wird. Es antwortet ja nur nicht mehr, da $cmd nicht gesetzt ist. Dadurch kommt er in die eine If-Abfrage nicht rein in der die EnOcean_A5Cmd($$$) aufegrufen wird. Also wird auch nix gesendet.
Gruß Georg
Zitat von: Schorsch M. schrieb am Mi, 13 März 2013 09:59Servus allesammt :)
Hi :)
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
Servus allesammt,
Ich hab mein Problem gelöst, oder besser verstanden. Ich erkläre es mal schrittweise :)
1. drücke den Push-Button des MD15 einmal.
Fhem ruft die Methode CommandSave(undef, undef); auf und setzt den subType als sensor in der Fhem.cfg und der Weboberfläsche
2. set TCM310 pairForSec 10 und drücke anschließend innerhalb von 10 Sekunden den Bush-Butten des MD15
3. MD15 piepst zweimal, dass Pairing war erfolgreich. Der subType wird in der Weboberfläsche direkt aktualisiert,
aber in der fhem.cfg nicht.
Was ich nun nicht wusste war, dass diese Änderung erst in der fhem.cfg gespeichert wird, wenn dort eine Änderung statfindet. Sprich der subType wird erst als MD15 gesetzt, wenn zum Beispiel ein anderes Gerät sich rückmeldet.
Um das Problem zu umgehen, so das der subType direkt beim Pairing als MD15 gesetzt wird, reicht eine kleine Änderung im Code. Ich rufe einfach CommandSave nach dem Pairing direkt auf und warte nicht bis eine Änderung stattfindet.
$st = $subTypes{$st} if($subTypes{$st});
$attr{$name}{subType} = $st;
Log 2, "Attr vor pair: $st";
if("$fn.$tp" eq "20.01" && $iohash->{pair}) { # MD15
select(undef, undef, undef, 0.1); # max 10 Seconds
EnOcean_A5Cmd($hash, "800800F0", "00000000");
select(undef, undef, undef, 0.5);
EnOcean_MD15Cmd($hash, $name, 128); # 128 == 20 degree C
}
CommandSave(undef, undef);Gruß Georg
Hallo Zusammen!
Ich arbeite mal Eure Tipps und Infos ab.
ZitatChristian, was für einen Empfänger nutzt du denn für EnOcean?
TCM3er oder TCM2er Serie?
TCM310
ZitatJa 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.
Sollte bei mir kein Problem sein, da ich erst mit BaseID+1 angefangen habe.
Zitatdu 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.
Habe wirklich kein Ahnung und werde mal versuchen Dein Beispiel einzubasteln.
Im FHEM-Log taucht nur folgendes beim teach-in auf. Mir sagt es nichts, aber vielleicht habt Ihr noch Ideen.
2013.03.14 19:24:42 5: TCM310_1/RAW: 55000A0701EBA580080A8001000EFA0001FFFFFFFF3300D2
2013.03.14 19:24:42 5: TCM310_1 dispatch EnOcean:A5:80080A80:01000EFA:00:01FFFFFFFF3300
2013.03.14 19:24:42 4: EnO_sensor_01000EFA: ORG:A5 DATA:80080A80 ID:01000EFA STATUS:00
2013.03.14 19:24:42 1: teach-in:EEP A5-20-01 Manufacturer: Kieback + Peter
2013.03.14 19:24:42 5: TCM310_1 sending 55000A0701EBA5800800F000000000000101000EFAFF00D5
2013.03.14 19:24:42 5: SW: 55000A0701EBA5800800F000000000000101000EFAFF00D5
2013.03.14 19:24:42 5: Triggering EnO_sensor_01000EFA (1 changes)
2013.03.14 19:24:42 5: Notify loop for EnO_sensor_01000EFA teach-in: EEP A5-20-01 Manufacturer: Kieback + Peter
2013.03.14 19:24:43 5: TCM310_1/RAW: 5500010002650000
2013.03.14 19:24:43 5: TCM310_1: RESPONSE: RET_OK
Werde jetzt mal weiterbasteln und testen...
Gruß, Christian
Zitat von: Schorsch M. schrieb am Do, 14 März 2013 16:16Zitat von: Schorsch M. schrieb am Mi, 13 März 2013 09:59Servus allesammt :)
Hi :)
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
Servus allesammt,
Ich hab mein Problem gelöst, oder besser verstanden. Ich erkläre es mal schrittweise :)
1. drücke den Push-Button des MD15 einmal.
Fhem ruft die Methode CommandSave(undef, undef); auf und setzt den subType als sensor in der Fhem.cfg und der Weboberfläsche
2. set TCM310 pairForSec 10 und drücke anschließend innerhalb von 10 Sekunden den Bush-Butten des MD15
3. MD15 piepst zweimal, dass Pairing war erfolgreich. Der subType wird in der Weboberfläsche direkt aktualisiert,
aber in der fhem.cfg nicht.
Was ich nun nicht wusste war, dass diese Änderung erst in der fhem.cfg gespeichert wird, wenn dort eine Änderung statfindet. Sprich der subType wird erst als MD15 gesetzt, wenn zum Beispiel ein anderes Gerät sich rückmeldet.
Um das Problem zu umgehen, so das der subType direkt beim Pairing als MD15 gesetzt wird, reicht eine kleine Änderung im Code. Ich rufe einfach CommandSave nach dem Pairing direkt auf und warte nicht bis eine Änderung stattfindet.
$st = $subTypes{$st} if($subTypes{$st});
$attr{$name}{subType} = $st;
Log 2, "Attr vor pair: $st";
if("$fn.$tp" eq "20.01" && $iohash->{pair}) { # MD15
select(undef, undef, undef, 0.1); # max 10 Seconds
EnOcean_A5Cmd($hash, "800800F0", "00000000");
select(undef, undef, undef, 0.5);
EnOcean_MD15Cmd($hash, $name, 128); # 128 == 20 degree C
}
CommandSave(undef, undef);
Gruß Georg
Ich nehme die Änderung mit in 10_EnOcean auf.
Zitat von: klaus.schauer schrieb am Do, 14 März 2013 20:54Ich nehme die Änderung mit in 10_EnOcean auf.
Danke, Klaus :)
Hi Christian,
Zitat von: krikan schrieb am Do, 14 März 2013 19:54Im FHEM-Log taucht nur folgendes beim teach-in auf. Mir sagt es nichts, aber vielleicht habt Ihr noch Ideen.
2013.03.14 19:24:42 5: TCM310_1/RAW: 55000A0701EBA580080A8001000EFA0001FFFFFFFF3300D2
2013.03.14 19:24:42 5: TCM310_1 dispatch EnOcean:A5:80080A80:01000EFA:00:01FFFFFFFF3300
2013.03.14 19:24:42 4: EnO_sensor_01000EFA: ORG:A5 DATA:80080A80 ID:01000EFA STATUS:00
2013.03.14 19:24:42 1: teach-in:EEP A5-20-01 Manufacturer: Kieback + Peter
2013.03.14 19:24:42 5: TCM310_1 sending 55000A0701EBA5800800F000000000000101000EFAFF00D5
2013.03.14 19:24:42 5: SW: 55000A0701EBA5800800F000000000000101000EFAFF00D5
2013.03.14 19:24:42 5: Triggering EnO_sensor_01000EFA (1 changes)
2013.03.14 19:24:42 5: Notify loop for EnO_sensor_01000EFA teach-in: EEP A5-20-01 Manufacturer: Kieback + Peter
2013.03.14 19:24:43 5: TCM310_1/RAW: 5500010002650000
2013.03.14 19:24:43 5: TCM310_1: RESPONSE: RET_OK
2013.03.14 19:24:42 4: EnO_sensor_01000EFA: ORG:A5 DATA:80080A80 ID:01000EFA STATUS:00Ist das eingehende Teach-In-Telegramm deines MD15, dasss stimmt soweit.
2013.03.14 19:24:42 5: TCM310_1 sending 55000A0701EBA5800800F000000000000101000EFAFF00D5Ist die Antwort von Fhem an dein MD15. Die 4 Datenbytes 80 08 00 F0 entsprechen dem 4BS Teach-In Telegramm und Fhem antwortet innerhalb Zeit in denen der MD15 eine Antwort erwartet.
Da du ja sagst das der MD15 zweimal piepst am Ende, sollte das Pairing also auf jedenfall geklappt haben.
Stell dir doch mal deine Log-Level auf 5 (falls noch nicht geschehen)damit du ein bissien mehr siehst im Logfile.
attr global verbose 5 und anschließend Save nicht vergessem ;)
Paire dein MD15 mit Fhem neu (save nicht vergessen ;) ) und dann setze die desired-temp auf 30°C. Geh in dein fhem-Logfile und warte das der MD15 was sendet.
Der MD15 sendet übrigens immer alle 10min, man kann fast die Uhr nach dem Teil stellen ^^
Irgendwann sollte ja dann mal ein Signal einegehen - das müsste dann so aussehen im Logfile.
TCM310 dispatch EnOcean:A5:00105E08:01018FB1:00:01FFFFFFFF30005E = db_1 (measuredtemp)
Fhem sollte dann darauf antworten mit
TCM310 sending 55000A0701EBA5BF5E0400[/b]00000000000101018FB1FF00C7
0x
BF => 191 192*40/255=29.9 => 30°C
Schau mal was passiert und geb mir dann Antwort.
Bin gespannt ob der MD15 oder Fhem keine Antwort mehr gibt.
Gruß Georg
Zitat von: Schorsch M. schrieb am Fr, 15 März 2013 11:30Hi Christian,
Irgendwann sollte ja dann mal ein Signal einegehen - das müsste dann so aussehen im Logfile.
TCM310 dispatch EnOcean:A5:00105E08:01018FB1:00:01FFFFFFFF3000
5E = db_1 (measuredtemp)
Fhem sollte dann darauf antworten mit
TCM310 sending 55000A0701EBA5BF5E0400[/b]00000000000101018FB1FF00C7
0xBF => 191 192*40/255=29.9 => 30°C
Schau mal was passiert und geb mir dann Antwort.
Bin gespannt ob der MD15 oder Fhem keine Antwort mehr gibt.
Gruß Georg
Hallo Georg,
habe ein wenig nach Deinem Input gebastelt. Eine Kommunikation zwischen FHEM und MD15 findet anscheinend regelmäßig alle 10 Minuten statt, aber der MD15 verändert seine Ventilstellung trotz Anforderung von 30 Grad nicht.
Das FHEM-Log hat alle 10 Minuten folgenden Inhalt
2013.03.15 20:58:40 5: TCM310_1/RAW: 55000A0701EBA500108B0801000EFA0001FFFFFFFF34001D
2013.03.15 20:58:40 5: TCM310_1 dispatch EnOcean:A5:00108B08:01000EFA:00:01FFFFFFFF3400
2013.03.15 20:58:40 0: EnO_sensor_01000EFA: ORG:A5 DATA:00108B08 ID:01000EFA STATUS:00Meine Interpretation des empfangenen Telegramms:
DB0 = 0x08 = 00001000 = data telegramm
DB1 = 0x8B = 139*40/255 = 22 °C ->
(Skala 0...255 = 0...40°C) -> 40/255*139+0 = 22
DB2 = 0x10 = 00010000 = alles false/off
DB3 = 0x00 = current value 0%
2013.03.15 20:58:40 5: TCM310_1 sending 55000A0701EBA5BF8B040000000000000101000EFAFF0064Meine Interpretation des gesendeten Telegramms:
DB0 = 0x00 = teach in telegramm
DB1 = 0x04 = 00000100 = temperature setpoint
DB2 = 0x8B = 18,2 ->
(Skala 255...0 = 0...40°C) -> 40/-255*139+40 = 18,2
DB3 = 0xBF = 30°C
2013.03.15 20:58:40 5: SW: 55000A0701EBA5BF8B040000000000000101000EFAFF0064
2013.03.15 20:58:40 5: Triggering EnO_sensor_01000EFA (11 changes)
2013.03.15 20:58:40 5: Notify loop for EnO_sensor_01000EFA 0 %
2013.03.15 20:58:41 5: TCM310_1/RAW: 5500010002650000
2013.03.15 20:58:41 5: TCM310_1: RESPONSE: RET_OKMich wundert das an den MD15 gesendete Telegramm, wenn ich es denn richtig interpretiert habe. Warum ist das ein Teach-In? Warum ist die Umrechnung/Skala im gesendeten Telegramm im DB2 abweichend vom Empfangstelegramm in DB1? Nach meiner Erinnerung sollten beide Werte gleich sein und dienen als Abstimmgrundlage. Liegt hier das Problem: FHEM und MD15 reden zwar miteinander aber der MD15 akzeptiert wegen falschen Temperaturwerte die Vorgabe nicht. Aber warum funktioniert es dann bei Dir? Fragen über Fragen.....
Über weiteren Input und Prüfung/Widerlegung meiner Telegramminterpretation wäre ich dankbar.
Gruß, Christian
Hallo Zusammen!
Meine MD15-Qual geht weiter. Ich habe jetzt meinen MD15 an meine kommerzielle Haussteuerung angelernt. Jetzt kann ich den MD15 problemlos steuern. Die Kommunikation zwischen Haussteuerung und MD15 habe ich dann mit FHEM belauscht.
Zunächst der LOG-Auszug, wenn ich die Soll-Temperatur auf 30°C hochsetze inklusive meiner versuchten Interpretation der Telegramme:
2013.03.16 07:00:25 5: TCM310_1/RAW: 55000A0701EBA504108C0801000EFA0001FFFFFFFF3400A0
2013.03.16 07:00:25 5: TCM310_1 dispatch EnOcean:A5:04108C08:01000EFA:00:01FFFFFFFF3400
DB0 = 0x08 = 00001000 = data telegramm
DB1 = 0x8C = 140*40/255 = 22 °C -> (Skala 0...255 = 0...40°C) -> 40/255*140+0 = 22
DB2 = 0x10 = 00010000 = alles false/off
DB3 = 0x04 = current value 0%
2013.03.16 07:00:25 3: EnOcean Unknown device with ID 01000EFA, please define it
2013.03.16 07:00:25 5: Triggering global (1 changes)
2013.03.16 07:00:25 5: Notify loop for global UNDEFINED EnO_sensor_01000EFA EnOcean 01000EFA
2013.03.16 07:00:25 5: TCM310_1/RAW: 55000A0701EBA5BF7F0408FFCD69AA0001FFFFFFFF4A00AD
2013.03.16 07:00:25 5: TCM310_1 dispatch EnOcean:A5:BF7F0408:FFCD69AA:00:01FFFFFFFF4A00
DB0 = 0x08 = data telegramm
DB1 = 0x04 = 00000100 = temperature setpoint
DB2 = 0x7F = 20,07 -> (Skala 255...0 = 0...40°C) -> 40/-255*127+40 = 20,07
DB3 = 0xBF = 30°C
2013.03.16 07:00:25 3: EnOcean Unknown device with ID FFCD69AA, please define it
Angaben aus der kommerziellen Haussteuerung:
Für den MD15 bekomme ich im Gegensatz zu den anderen Aktoren 2 Adressen angezeigt
1.Adresse: 2AH
2.Adresse: 0701000EFAh
ID-Basis des Gateways: FFCD6980h
Gateway zur Ansteuerung: BootUp USB2-EnOcean868 mit TCM300-Chip
Log-Auszug der Kommunikation nach 10 Minuten ohne Änderung an den Werten in der Haussteuerung:
2013.03.16 07:11:34 5: TCM310_1/RAW: 55000A0701EBA564108C0801000EFA0001FFFFFFFF310021
2013.03.16 07:11:34 5: TCM310_1 dispatch EnOcean:A5:64108C08:01000EFA:00:01FFFFFFFF3100
2013.03.16 07:11:34 3: EnOcean Unknown device with ID 01000EFA, please define it
2013.03.16 07:11:34 5: Triggering global (1 changes)
2013.03.16 07:11:34 5: Notify loop for global UNDEFINED EnO_sensor_01000EFA EnOcean 01000EFA
2013.03.16 07:11:34 5: TCM310_1/RAW: 55000A0701EBA5BF7F0408FFCD69AA0001FFFFFFFF500078
2013.03.16 07:11:34 5: TCM310_1 dispatch EnOcean:A5:BF7F0408:FFCD69AA:00:01FFFFFFFF5000
2013.03.16 07:11:34 3: EnOcean Unknown device with ID FFCD69AA, please define it
2013.03.16 07:11:34 5: Triggering global (1 changes)
2013.03.16 07:11:34 5: Notify loop for global UNDEFINED EnO_sensor_FFCD69AA EnOcean FFCD69AA
Folgender LOG-Auszug ergibt sich, wenn ich die Soll-Pos des Ventils heruntersetze:
2013.03.16 07:21:35 5: TCM310_1/RAW: 55000A0701EBA564108D0801000EFA0001FFFFFFFF3100C4
2013.03.16 07:21:35 5: TCM310_1 dispatch EnOcean:A5:64108D08:01000EFA:00:01FFFFFFFF3100
2013.03.16 07:21:35 3: EnOcean Unknown device with ID 01000EFA, please define it
2013.03.16 07:21:35 5: Triggering global (1 changes)
2013.03.16 07:21:35 5: Notify loop for global UNDEFINED EnO_sensor_01000EFA EnOcean 01000EFA
2013.03.16 07:21:35 5: TCM310_1/RAW: 55000A0701EBA5047F0008FFCD69AA0001FFFFFFFF4D002A
2013.03.16 07:21:35 5: TCM310_1 dispatch EnOcean:A5:047F0008:FFCD69AA:00:01FFFFFFFF4D00
2013.03.16 07:21:35 3: EnOcean Unknown device with ID FFCD69AA, please define it
2013.03.16 07:21:35 5: Triggering global (1 changes)
2013.03.16 07:21:35 5: Notify loop for global UNDEFINED EnO_sensor_FFCD69AA EnOcean FFCD69AA
Und nochmal Soll-Pos heruntergesetzt:
2013.03.16 07:32:49 5: TCM310_1/RAW: 55000A0701EBA500108E0801000EFA0002FFFFFFFF330068
2013.03.16 07:32:49 5: TCM310_1 dispatch EnOcean:A5:00108E08:01000EFA:00:02FFFFFFFF3300
2013.03.16 07:32:49 3: EnOcean Unknown device with ID 01000EFA, please define it
2013.03.16 07:32:49 5: Triggering global (1 changes)
2013.03.16 07:32:49 5: Notify loop for global UNDEFINED EnO_sensor_01000EFA EnOcean 01000EFA
2013.03.16 07:32:49 5: TCM310_1/RAW: 55000A0701EBA5037F0008FFCD69AA0001FFFFFFFF4D0024
2013.03.16 07:32:49 5: TCM310_1 dispatch EnOcean:A5:037F0008:FFCD69AA:00:01FFFFFFFF4D00
2013.03.16 07:32:49 3: EnOcean Unknown device with ID FFCD69AA, please define it
Habt ihr noch rgendwelche Ideen?
Danke, Christian
Servus,
interessanter Weiße wird DB_0 in der Richtung controller to the actuator im Handbuch von Kieback&Peter für den MD15 gar nicht erst beschrieben.
https://extranet.kieback-peter.de/download/3.09-20.315-01-EN-MD15-FTL-xx-2012-12-07.pdf?37748 (//extranet.kieback-peter.de/download/3.09-20.315-01-EN-MD15-FTL-xx-2012-12-07.pdf?37748)
Im enocean equipment profile hingegen schon.
Fragen über Fragen
Zitat von: Schorsch M. schrieb am Sa, 16 März 2013 11:44Servus,
interessanter Weiße wird DB_0 in der Richtung controller to the actuator im Handbuch von Kieback&Peter für den MD15 gar nicht erst beschrieben.
https://extranet.kieback-peter.de/download/3.09-20.315-01-EN-MD15-FTL-xx-2012-12-07.pdf?37748
Im enocean equipment profile hingegen schon.
Fragen über Fragen
Hi,
bisher habe ich immer in der EEP 2.1-Beschreibung auf der Homepage von Enocean geschaut. Das Handbuch von Kieback&Peter schaue ich mir auch mal an; danke für den Hinweis darauf. Irgendwie sollte das Ding doch mit FHEM laufen....
Gruß, Christian
PS: Es gibt anscheinend auch ein neues EEP 2.5 (
http://www.enocean-alliance.org/de/enocean-alliance-entwickelt-funkstandard-fuer-gruene-gebaeude-weiter/)
Hallo Zusammen!
Nach langem Basteln bin ich jetzt nach kleinen Codeänderungen in 10_EnOcean.pm in der Lage den MD15 mit FHEM zu steuern und nicht nur zu pairen. Ich habe dazu folgende Anpassung in Sub EnOcean_MD15Cmd($$$) vorgenommen/ersetzt:
Zeile 1215 für actuator: $msg = sprintf("%02X7F0008", $arg1);
Zeile 1218 und 1219 für desired-temp: $msg = sprintf("%02X7F0408", $arg1*255/40);
Rot markiert sind meine geänderten Werte.
In db_0 habe ich beide Telegramme als Datentelegramm (0x08) markiert, vorher waren es Lerntelegramme.
In db_2 habe ich die Konstante 0x7F aufgenommen; den Wert habe ich aus den mitgeschnittenen Daten (siehe vorherige Beiträge). Hier muss wohl nicht die aktuelle Temperatur stehen; die genaue Bedeutung der Konstante ist mir leider nicht klar.
Ich habe den MD15 jetzt 2 mal erfolgreich neu angelernt und sowohl Befehle über set actuator und set desired-temp verschickt, die jetzt auch zu (hörbaren) Änderungen der Ventilstellung geführt haben. Das Fhem-Log hierzu habe ich zur Info mal angehängt.
Es wäre schön, wenn die MD15-Besitzer das einmal testen und Rückmeldung geben könnten. Bei funktioniert es zwar, aber da ich die Telegramminhalte des MD15 nicht wirklich verstanden habe, kann das auch ein Zufallstreffer bei mir sein. Vielleicht hat auch jemand mittlerweile weitergehende Infos zum Telegramm.
Der set-Befehl "initialize" ist mir unverständlich; hat keiner eine Ahnung was der bewirken soll?
Gruß, Christian
Ich habe die EEP-Profil Vorgaben mal zur Hand genommen:
1.In DB3 sollte nur dann die Temperatur gesendet werden, wenn Bit DB1.2 true. Derzeit wird DB1 immer mit 0x00 gesendet.
2. Der aktuelle Temperaturwert in DB2 ist in invers zu DB3, was bisher nicht berücksichtigt ist.
Der "initialize" Befehl scheint nicht ganz nebensächlich zu sein. Folgende Aktionen sollte er beim MD15 auslösen:
1. DB1.6 = true: Run init sequence
2. DB1.5 = true: Lift set
3. DB1.2 = true: Set Point selection >> Inhalt von DB3 ist dann Temperatur, MD15 reagiert auf room sensor (DB2 ?) und nutzt den internen PI-Regler
Vielleicht sollte man deshalb den "initialize" Befehl nach dem Anlernen senden und damit den MD15 in den "richtigen" Betriebsmodus bringen. Mir ist aber nicht klar, ob Set Point selection dann im MD15 dauerhaft gespeichert ist und nicht mit jedem set desired-temp mitgesendet werden muss.
Im übrigen wird der "initialize" Befehl derzeit auch als teach-in Telegram gesendet.
Hallo Klaus!
Zitat1.In DB3 sollte nur dann die Temperatur gesendet werden, wenn Bit DB1.2 true. Derzeit wird DB1 immer mit 0x00 gesendet.
Verstehe ich nicht; DB1 wird doch bei desired-temp mit 0x04 gesendet also ist DB1.2 auf true? (Zeile 1218 10_Enocean.pm)
Zitat2. Der aktuelle Temperaturwert in DB2 ist in invers zu DB3, was bisher nicht berücksichtigt ist.
Das hatte ich auch mal festgestellt (siehe vorherige Beiträge) und daher ich mal probiert; hatte aber keine Auswirkung in Form von Ventilreaktionen. Nur die mitgeschnitte Konstante Ox7F führt zum Erfolg.
ZitatDer "initialize" Befehl scheint nicht ganz nebensächlich zu sein. Folgende Aktionen sollte er beim MD15 auslösen:
1. DB1.6 = true: Run init sequence
2. DB1.5 = true: Lift set
3. DB1.2 = true: Set Point selection >> Inhalt von DB3 ist dann Temperatur, MD15 reagiert auf room sensor (DB2 ?) und nutzt den internen PI-Regler
Vielleicht sollte man deshalb den "initialize" Befehl nach dem Anlernen senden und damit den MD15 in den "richtigen" Betriebsmodus bringen. MIr ist aber nicht klar, ob Set Point selection dann im MD15 dauerhaft gespeichert ist und nicht mit jedem set desired-temp mitgesendet werden muss.
Also ich vermute anhand der mitgeschnittenen Telegramm der komm. Software, dass das nicht dauerhaft gespeichert wird. Ich hatte sowohl mit Temperatur und Ventilstellung gesteuert und keine Änderung bei den Telegrammen in DB1 festgestellt (übersehen?). Es war nur 0x00 (Ventilsteuerung) und 0x04 (Temperatursteuerung)in DB1 vorhanden. Auch mit meinem Codeänderung an 10_Enocean.PM habe munter Temperatur und Ventil abwechselnd geändert und immer eine Motorreaktion gehabt. Ob die richtig ist, weiß ich natürlich nicht. Darum verstehe ich "initalize" eben nicht. Werde noch mal systematisch versuchen Telegramme mitzuschneiden. Das wird nur was dauern.
Gruß, Christian
Zitat von: krikan schrieb am So, 17 März 2013 21:19Hallo Klaus!
Zitat1.In DB3 sollte nur dann die Temperatur gesendet werden, wenn Bit DB1.2 true. Derzeit wird DB1 immer mit 0x00 gesendet.
Verstehe ich nicht; DB1 wird doch bei desired-temp mit 0x04 gesendet also ist DB1.2 auf true? (Zeile 1218 10_Enocean.pm)
Zitat2. Der aktuelle Temperaturwert in DB2 ist in invers zu DB3, was bisher nicht berücksichtigt ist.
Das hatte ich auch mal festgestellt (siehe vorherige Beiträge) und daher ich mal probiert; hatte aber keine Auswirkung in Form von Ventilreaktionen. Nur die mitgeschnitte Konstante Ox7F führt zum Erfolg.
ZitatDer "initialize" Befehl scheint nicht ganz nebensächlich zu sein. Folgende Aktionen sollte er beim MD15 auslösen:
1. DB1.6 = true: Run init sequence
2. DB1.5 = true: Lift set
3. DB1.2 = true: Set Point selection >> Inhalt von DB3 ist dann Temperatur, MD15 reagiert auf room sensor (DB2 ?) und nutzt den internen PI-Regler
Vielleicht sollte man deshalb den "initialize" Befehl nach dem Anlernen senden und damit den MD15 in den "richtigen" Betriebsmodus bringen. MIr ist aber nicht klar, ob Set Point selection dann im MD15 dauerhaft gespeichert ist und nicht mit jedem set desired-temp mitgesendet werden muss.
Also ich vermute anhand der mitgeschnittenen Telegramm der komm. Software, dass das nicht dauerhaft gespeichert wird. Ich hatte sowohl mit Temperatur und Ventilstellung gesteuert und keine Änderung bei den Telegrammen in DB1 festgestellt (übersehen?). Es war nur 0x00 (Ventilsteuerung) und 0x04 (Temperatursteuerung)in DB1 vorhanden. Auch mit meinem Codeänderung an 10_Enocean.PM habe munter Temperatur und Ventil abwechselnd geändert und immer eine Motorreaktion gehabt. Ob die richtig ist, weiß ich natürlich nicht. Darum verstehe ich "initalize" eben nicht. Werde noch mal systematisch versuchen Telegramme mitzuschneiden. Das wird nur was dauern.
Gruß, Christian
DB1.2 = true bei der Temperaturvorgabe hatte ich nicht gesehen.
Nur wenn in DB2 immer 7F = 20°C gesendet wird, kann der interne PI-Regler seine Referenz nie von einem getrennten Thermostat erhalten und nur auf sein eingebautes Thermostat reagieren. Wozu braucht man dann die Variable? Kann das nicht wirklich Zufall sein? Kann man eindeutig nur bei diesem Wert den MD15 steuern?
Nur wenn in DB2 immer 7F = 20°C gesendet wird, kann der interne PI-Regler seine Referenz nie von einem getrennten Thermostat erhalten und nur auf sein eingebautes Thermostat reagieren. Wozu braucht man dann die Variable? Kann das nicht wirklich Zufall sein? Kann man eindeutig nur bei diesem Wert den MD15 steuern?
Zumindest kann ich meinen MD15 mit 7F steuern, während Original-10-Enocean.pm-Werte bzw. skalenangepaßte Werte bei mir zu keiner Ventiländerung führten. Mehr habe ich nicht probiert, die 10-Minuten-Wartzeit auf die Ventiländerung sind lange ;-). Darum meine Bitte an andere MD15-Besitzer das mal zu testen. Frage mich, ob es eine Rolle spielt, dass FHEM beim Teach-In 0x80 als Temperatur vorgibt (annähernd 7F)? Dann müsste meine kommerzielle Haussteuerung beim Teach-In auch 20°C vorgeben; wäre eine interessanter Zufall...
Wozu man die Variable braucht? Mmh, dazu fehlt mir noch eindeutig der große Zusammenhang. Ich bin nur froh, dass ich endlich eine Ventilreaktion habe.
Wenn man sich das EEP-Profil und die Unterlagen von Kieback&Peter ansieht, macht der derzeitige Befehl "set initialize" wahrscheinlich keinen Sinn. Ich vermute, der Befehl ist so bisher gar nicht funktionsfähig.
1. Lift set, Valve open usw. werden lt. Kieback&Peter nur im Maintenance Mode vom Regler akzeptiert. Ich kann aber nicht erkennen, dass dieser Modus irgendwo eingeschaltet wird oder ist.
2. Die Kombination aus zwei Maintenance Befehlen Lift set und Valve open finde ich ebenfalls ungewöhnlich. Zudem wird mit "set initialize" derzeit auch set point selection auf temperatur gesetzt. Das passt auch nicht.
M. E. wäre es sinnvoll einen Satz von Maintenance Befehlen (runInit, liftSet, valveOpen, valveClosed) in das Profil aufzunehmen und damit zu testen.
Dabei würde mich auch intessieren, wie man wieder aus dem Maintenance Mode in den Betriebsmodus wechseln kann und welche Auswirkungen das "summer bit" z. B. auf das Kommunikationsverhalten des MD15 hat.
Falls sich Tester finden, würde ich die zusätzlichen Befehle bei Gelegenheit vorbereiten.
Hallo Klaus,
ZitatFalls sich Tester finden, würde ich die zusätzlichen Befehle bei Gelegenheit vorbereiten.
ich bin bei den MD15 Tests auf jeden Fall dabei.
Soll ich noch Mitschnitte der Kommunikation MD15 liefern?
Zitatwelche Auswirkungen das "summer bit" z. B. auf das Kommunikationsverhalten des MD15 hat.
MD15 sendet dann zwecks Batterieschonung seinen Status nur noch stündlich.
Frage mich nur, was der Maintance Modus bringen soll? Das Eichen des MD15 findet doch statt, wenn ich den MD15 auf das Ventil aufschraube und anschließend erst die Batterien einlege.
Gruß, Christian
Zitat von: krikan schrieb am Mo, 18 März 2013 14:17Hallo Klaus,
ZitatFalls sich Tester finden, würde ich die zusätzlichen Befehle bei Gelegenheit vorbereiten.
ich bin bei den MD15 Tests auf jeden Fall dabei.
Soll ich noch Mitschnitte der Kommunikation MD15 liefern?
Zitatwelche Auswirkungen das "summer bit" z. B. auf das Kommunikationsverhalten des MD15 hat.
MD15 sendet dann zwecks Batterieschonung seinen Status nur noch stündlich.
Frage mich nur, was der Maintance Modus bringen soll? Das Eichen des MD15 findet doch statt, wenn ich den MD15 auf das Ventil aufschraube und anschließend erst die Batterien einlege.
Gruß, Christian
Na ja ich bin eben manchmal Perfektionist. Sonst hätte ich es mir auch mit dem automatischen teach-in für die A5-Profile sparen können. Attribut eintragen und gut is :-)
Natürlich ist es augenblicklich wirklich wichtiger und entscheidender die Grundfunktionen des MD15-Profil ans Laufen zu bringen. Aber da geht es ja wirklich voran.
Hallo Klaus,
ZitatNa ja ich bin eben manchmal Perfektionist. Sonst hätte ich es mir auch mit dem automatischen teach-in für die A5-Profile sparen können. Attribut eintragen und gut is :-)
Natürlich ist es augenblicklich wirklich wichtiger und entscheidender die Grundfunktionen des MD15-Profil ans Laufen zu bringen. Aber da geht es ja wirklich voran.
Sorry, wenn ich mich mißverständlich ausgedrückt habe. Das war keinesfalls als Kritik an Dir aufzufassen. Bin beim Perfektionismus auf Deiner Seite und dankbar für Deine grandiose Enocean-Leistung in der kurzen Zeit. Ich frage mich wirklich wofür der Maintance-Modus beim MD15 gut ist.
Noch mal zu meinen Mitschnitten. Kannst Du die Logs vom Mitschnitt gebrauchen. Logge seit gestern mit und habe auch das Fremd-teach-in geloggt...
Gruß, Christian
Hallo Zusammen,
leider konnte ich in den letzten Tagen mit dem MD15 nicht weiter Testen.
ZitatFrage mich nur, was der Maintance Modus bringen soll? Das Eichen des MD15 findet doch statt, wenn ich den MD15 auf das Ventil aufschraube und anschließend erst die Batterien einlege.
Ich glaube das der Maintenance Modus mit dem Service Modus des RBW322-FtL gleich zu setzen ist. --> Am RBW322 kann man somit die Ventilstellung des MD15 vorgeben. --> das hat bei mir aber leider auch noch nicht funktioniert, kann aber an meiner Hardware liegen.
ZitatFalls sich Tester finden, würde ich die zusätzlichen Befehle bei Gelegenheit vorbereiten.
Helfe dabei sehr gerne mit.
@ kirkan, mit welcher Software schneidest du die Telegramme mit? Empfehlung = DolphinView (Braucht man leider einen zweiten TCM :-(
MfG, Matze
Hallo!
ZitatIch glaube das der Maintenance Modus mit dem Service Modus des RBW322-FtL gleich zu setzen ist. --> Am RBW322 kann man somit die Ventilstellung des MD15 vorgeben. --> das hat bei mir aber leider auch noch nicht funktioniert, kann aber an meiner Hardware liegen.
Die Ventilstellung kann ich aus FHEM mit "set actuator" vorgeben. Dafür brauche ich doch keinen Maintance/Service-Modus. Oder muss ich mir das als Setzen der Standard-Minimal- bzw. Standard-Maximal-Stellung vorstellen? Fragen über Fragen....
Zitat@ kirkan, mit welcher Software schneidest du die Telegramme mit? Empfehlung = DolphinView (Braucht man leider einen zweiten TCM :-(
Ich logge mit FHEM und verbose 5 mit einem 2. TCM. Mit Dolphinview Basic habe ich nur in grauer Vorzeit experimentiert. Habe es dann nicht mehr genutzt, da es mir nach meiner Erinnerung zu wenig Infos lieferte. Vielleicht sollte ich es mir noch mal anschauen!?
Gruß, Christian