Autor Thema: MD15 Subtype wird falsch gesetzt  (Gelesen 22727 mal)

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1261
Aw: MD15 Subtype wird falsch gesetzt
« Antwort #15 am: 14 März 2013, 12:31:25 »
Zitat von: Schorsch M. schrieb am Do, 14 März 2013 10:57
Zitat von: klaus.schauer schrieb am Do, 14 März 2013 09:49

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.


Kommt die Kommunikation später wieder zustande, sobald ich in Fhem einen neuen Befehl setze? Dann wäre der Befehl als "reset" vielleicht sinnvoll.

Offline Schorsch M.

  • Jr. Member
  • **
  • Beiträge: 66
Aw: MD15 Subtype wird falsch gesetzt
« Antwort #16 am: 14 März 2013, 16:15:59 »
Zitat von: klaus.schauer schrieb am Do, 14 März 2013 12:31
Zitat von: Schorsch M. schrieb am Do, 14 März 2013 10:57
Zitat von: klaus.schauer schrieb am Do, 14 März 2013 09:49

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.


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

Offline Schorsch M.

  • Jr. Member
  • **
  • Beiträge: 66
Aw: MD15 Subtype wird falsch gesetzt
« Antwort #17 am: 14 März 2013, 16:16:28 »
Zitat von: Schorsch M. schrieb am Mi, 13 März 2013 09:59
Servus 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



Offline krikan

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7044
Aw: MD15 Subtype wird falsch gesetzt
« Antwort #18 am: 14 März 2013, 19:54:36 »
Hallo Zusammen!

Ich arbeite mal Eure Tipps und Infos ab.

Zitat

Christian, was für einen Empfänger nutzt du denn für EnOcean?
TCM3er oder TCM2er Serie?

TCM310

Zitat

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.

Sollte bei mir kein Problem sein, da ich erst mit BaseID+1 angefangen habe.

Zitat
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.

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

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1261
Aw: MD15 Subtype wird falsch gesetzt
« Antwort #19 am: 14 März 2013, 20:54:44 »
Zitat von: Schorsch M. schrieb am Do, 14 März 2013 16:16
Zitat von: Schorsch M. schrieb am Mi, 13 März 2013 09:59
Servus 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.

Offline Schorsch M.

  • Jr. Member
  • **
  • Beiträge: 66
Aw: MD15 Subtype wird falsch gesetzt
« Antwort #20 am: 15 März 2013, 11:29:37 »
Zitat von: klaus.schauer schrieb am Do, 14 März 2013 20:54


Ich nehme die Änderung mit in 10_EnOcean auf.


Danke, Klaus :)

Offline Schorsch M.

  • Jr. Member
  • **
  • Beiträge: 66
Aw: MD15 Subtype wird falsch gesetzt
« Antwort #21 am: 15 März 2013, 11:30:48 »
Hi Christian,
Zitat von: krikan schrieb am Do, 14 März 2013 19:54


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


2013.03.14 19:24:42 4: EnO_sensor_01000EFA: ORG:A5 DATA:80080A80 ID:01000EFA STATUS:00

Ist das eingehende Teach-In-Telegramm deines MD15, dasss stimmt soweit.

2013.03.14 19:24:42 5: TCM310_1 sending 55000A0701EBA5800800F000000000000101000EFAFF00D5
Ist 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: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

Offline krikan

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7044
Aw: MD15 Subtype wird falsch gesetzt
« Antwort #22 am: 15 März 2013, 23:54:55 »
Zitat von: Schorsch M. schrieb am Fr, 15 März 2013 11:30
Hi 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:00

Meine 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 55000A0701EBA5BF8B040000000000000101000EFAFF0064
Meine 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_OK


Mich 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

Offline krikan

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7044
Aw: MD15 Subtype wird falsch gesetzt
« Antwort #23 am: 16 März 2013, 07:51:20 »
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

Offline Schorsch M.

  • Jr. Member
  • **
  • Beiträge: 66
Aw: MD15 Subtype wird falsch gesetzt
« Antwort #24 am: 16 März 2013, 11:44:17 »
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
Im enocean equipment profile hingegen schon.

Fragen über Fragen

Offline krikan

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7044
Aw: MD15 Subtype wird falsch gesetzt
« Antwort #25 am: 16 März 2013, 20:51:02 »
Zitat von: Schorsch M. schrieb am Sa, 16 März 2013 11:44
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
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/)

Offline krikan

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7044
Aw: MD15 Subtype wird falsch gesetzt
« Antwort #26 am: 17 März 2013, 17:20:01 »
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

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1261
Aw: MD15 "set" sollte genauer getestet werden
« Antwort #27 am: 17 März 2013, 20:44:10 »
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.

Offline krikan

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7044
Aw: MD15 "set" sollte genauer getestet werden
« Antwort #28 am: 17 März 2013, 21:19:14 »
Hallo Klaus!

Zitat
1.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)

Zitat
2. 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.

Zitat
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.

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

Offline klaus.schauer

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1261
Aw: MD15 "set" sollte genauer getestet werden
« Antwort #29 am: 17 März 2013, 21:39:02 »
Zitat von: krikan schrieb am So, 17 März 2013 21:19
Hallo Klaus!

Zitat
1.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)

Zitat
2. 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.

Zitat
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.

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?

 

decade-submarginal