[gelöst] Service-Funktionen Kleinstellantrieb MD15

krikan · 31 Mai 2014, 13:59:36

Vergabe der subDef funktioniert korrekt, wenn ich eine komplett neue fhem.cfg nutze.

Wenn ich aber meine vorhandene fhem.cfg nehme und nach löschen des vorhandenen Devices, save, restart einen neuen Teach-In mache, wird subDef -wie gestern geschrieben- immer "00000000". In der vorhandenen fhem.cfg waren beim Anlernen immer andere Aktoren mit subDef "00000000" enthalten; könnte das einen Einfluss haben?

klaus.schauer · 31 Mai 2014, 22:23:08

Das ist ja sehr ungewöhnlich. Ich lösche das jeweilige Device vor dem neuen Anlernen immer unmittelbar in der fhem.cfg. Bisher gab es dann keine Wechselwirkungen.

Klappt das Anlernen des MD15 jetzt und sind damit dann alle Funktionen auch die Wartungsfunktionen ausführbar?

krikan · 31 Mai 2014, 22:31:09

Ungewöhnlich und führt dazu, dass ich nur mit neuer fhem.cfg sinnvoll testen kann. Dann funktioniert md15. Der Sinn der Wartungs-Funktionen ist für mich aber unklar. Außer, dass die Batterien des md15 jetzt leer waren. Die für mich interessante Service Funktion SummerBit müsste bitte noch eingebaut werden. Hatte ich in oben angehängtem Code implementiert.

klaus.schauer · 01 Juni 2014, 10:57:55

attr summerMode off|on für MD15 ist jetzt auch verfügbar. Bitte testen.

krikan · 01 Juni 2014, 13:13:59

Hallo Klaus,

es gibt mit der letzten Version leider noch ein Problem beim Senden der Telegramme. Es scheint die SenderId nicht mit an den MD15 übertragen zu werden.

Laut Log:

Code Auswählen

2014.06.01 12:43:26 5: SW: 55000A0701EBA582700408000301000EFAFF002F

Richtig wäre folgende Form:

Code Auswählen

2014.05.30 11:20:20 5: SW: 55000A0701EBA5826B0C08FFAEEE82000301000EFAFF00CE

List ergibt:

Code Auswählen


Internals: 
   CMD        desired-temp 
   DEF        01000EFA 
   IODev      TCM310_3 
   LASTInputDev TCM310_3 
   MSGCNT     3 
   NAME       Stellventil 
   NOTIFYDEV  global 
   NR         181 
   STATE      0 
   TCM310_3_DestinationID FFFFFFFF 
   TCM310_3_MSGCNT 3 
   TCM310_3_PacketType 1 
   TCM310_3_RSSI -52 
   TCM310_3_ReceivingQuality excellent 
   TCM310_3_RepeatingCounter 0 
   TCM310_3_SubTelNum 6 
   TCM310_3_TIME 2014-06-01 12:43:26 
   TYPE       EnOcean 
   Readings: 
     2014-06-01 11:56:37   CMD             desired-temp 
     2014-06-01 12:43:26   actuatorStatus  ok 
     2014-06-01 12:43:26   battery         ok 
     2014-06-01 12:43:26   cover           closed 
     2014-06-01 12:43:26   currentValue    0 
     2014-06-01 11:56:37   desired-temp    20.5 
     2014-06-01 12:43:26   energyInput     disabled 
     2014-06-01 12:43:26   energyStorage   empty 
     2014-06-01 12:43:26   measured-temp   22.3 
     2014-06-01 12:43:26   selfCtl         off 
     2014-06-01 12:43:26   serviceOn       no 
     2014-06-01 12:43:26   state           0 
     2014-05-31 16:11:57   teach-in        EEP A5-20-01 Manufacturer: Kieback + Peter 
     2014-06-01 12:43:26   tempSensor      ok 
     2014-06-01 12:43:26   temperature     22.4 
     2014-06-01 12:43:26   window          closed 
Attributes: 
   IODev      TCM310_3 
   actualTemp 22.6 
   comMode    biDir 
   destinationID unicast 
   manufID    00A 
   room       EnOcean 
   subDef     FFAEEE82 
   subType    hvac.01 
   summerMode off 
   verbose    5

Das ist aus meiner laufenden Installation. Kann auch sein, dass dieses Problem schon in den vorherigen Versionen existiert, da ich meine Experimente (welche Version, wann) nicht genau nachvollziehen kann. Sorry.

Zeile 4065:

Code Auswählen

my $subDef = ReadingsVal($name, "subDef", undef);
Sonst hast Du per AttrVal zugewiesen.

Gruß, Christian

edit: Codezeile korrigiert

klaus.schauer · 01 Juni 2014, 14:43:31

War natürlich ein Fehler. Habe ich geändert. Danke für den Hinweis. Ich hoffe es passt jetzt.

krikan · 01 Juni 2014, 14:44:15

Habe Zeile 4065 in 10_EnOcean.pm ausgetauscht gegen:

Code Auswählen

my $subDef = AttrVal($name, "subDef", undef);
Weitere Änderungen habe ich nicht vorgenommen.
Dann funktioniert der SummerMode bei Steuerung über desired-temp. Steuerung über actuator habe ich noch nicht getestet.
Die anderen Servicefunktionen werde ich noch mal probieren. Wird aber ein paar Tage dauern; wenn Du nichts geändert hast, sollten die aber auch laufen.

klaus.schauer · 01 Juni 2014, 20:20:18

Hier die Fassung der Dateien, die ich alsbald verteilen wollte.

krikan · 01 Juni 2014, 21:19:52

Hallo Klaus!

Habe die beiden neuen Dateien in meine laufende Installation von Fhem eingespielt. Jetzt startet Fhem auf der Fritzbox nicht mehr. Letzte Zeilen im Log jeweils:

Code Auswählen

2014.06.01 21:06:07 3: TCM310_3 device opened
2014.06.01 21:06:07 2: TCM get TCM310_3 baseID
2014.06.01 21:06:07 5: TCM TCM310_3 sending 5500010005700838
2014.06.01 21:06:07 5: SW: 5500010005700838
2014.06.01 21:06:07 5: TCM RAW ReadAnswer: 005500050102DB00

Habe dann die Dateien von heute morgen wieder eingespielt. Dann geht es wieder problemlos.

Hast Du noch etwas in 00_TCM.pm geändert, was dieses Verhalten erklären könnte?

Gruß, Christian

klaus.schauer · 01 Juni 2014, 21:33:33

10_TCM ist unverändert. Die neue 10_EnOcean läuft bei mir problemlos auf der FRITZ!Box 7490 und Raspberry PI.

krikan · 01 Juni 2014, 21:38:29

Dann verstehe ich es nicht. Werde noch mal schrittweise und in Ruhe alles durchgehen. Komme dazu aber erst im Laufe der Woche.

krikan · 03 Juni 2014, 09:41:51

Hat mir keine Ruhe gelassen, habe diese Nacht daher einige Stunden gebastelt und probiert. Ich bin aber (leider) zu keinem für mich sinnvoll auswertbaren Ergebnis gekommen:

Bei Einsatz der letzten aktualisierten TCM und EnOcean-Version aus diesem Thread mit meiner vorhanden fhem.cfg startet Fhem nicht korrekt, sondern bleibt immer bei "TCM get TCM310_3 baseID" (letzter Eintrag im Log) hängen. Interessanterweise funktioniert die vorletzte TCM und EnOcean-Version (edit: aus diesem Thread) plötzlich auch nicht mehr mit meiner vorhandenen fhem.cfg, obwohl dies vorher problemlos war. Mit neuer fhem.cfg funktionieren beide Versionen dagegen immer. Darum dachte ich schon an einen Defekt des Gateways.

Nehme ich aber die alte TCM und EnOcean-Version aus dem SVN funktioniert meine vorhandene fhem.cfg problemlos. Bis auf ein Mal bei dem ich im Log auf "get basteID" eine "bogus answer" (Indiz für Gateway-Defekt?) stehen hatte, aber dennoch alle EnOcean-Funktionen gegeben waren.

Alle Test habe ich auf meiner 7390 durchgeführt. Diese läuft zugegebenermaßen am Limit (HMLAN, RFXCOM, 2xRS232-EHZ, TCM). Aber bisher eben stabil.

Eigentlich habe ich nach meinen Test mehr Fragen als Antworten gefunden. Ob meine Probleme mit den Änderungen an den Modulen zusammenhängen, bezweifle ich mittlerweile. Nur die Änderungen am Timing geben mir noch "Hoffnung". Nur verstehe ich diese Timing-Änderungen nicht.

Als Testplattform ist meine Installation wohl momentan nicht sehr geeignet.

klaus.schauer · 03 Juni 2014, 15:00:45

Schade eigentlich. Der Fehler beim Abfragen der baseID könnte bei der Vielzahl der Schnittstellen, die an der FRITZ!Box genutzt werden, auf eine falsche Zuordnung der Transceiver zurückzuführen sein. Ich hatte letztlich ein ähnliches Problem. Ich habe dann die Schnittstellendefinitionen in der Fhem Konfiguration herausgenommen und die Geräte (TCM, CUL) erneut per autocreate aufgenommen. Nur warum das geholfen hat, ist mir nicht klar.

krikan · 03 Juni 2014, 21:13:12

Danke, Klaus.

Das wars anscheinend! Nach Löschen der Schnittstellendefinitionen und Neustart läuft es jetzt mit meiner vorhanden fhem.cfg. Verstehen kann ich es auch nicht. Sicherheitshalber habe ich mal autocreate ausgeschaltet.

Gruß, Christian

krikan · 05 Juni 2014, 20:36:52

Testergebnisse MD15-FTL mit letzter Version im Thread:

attr sommerMode funktioniert
Service Funktionen (Maintance Mode) runInit, valveOpen und valveClosed lösen Reaktionen des Aktors aus
Service Funktion liftSet hat keine Auswirkung; entspricht Angabe in Anleitung "für MD15-FTL-xx nicht zutreffend"
Sinn der im commandref nicht erwähnten Funktion "initalize" ist unklar

Teach-In wegen des (meines) fragilen Testsystems nicht erneut getestet.