[gelöst] Service-Funktionen Kleinstellantrieb MD15

Begonnen von krikan, 27 Mai 2014, 08:46:40

Vorheriges Thema - Nächstes Thema

krikan

Sämtliche Servicefunktionen (Maintance Mode) des MD15 haben bei mir mit Fhem keine Auswirkungen. Nach Absetzen des entsprechenden Set-Kommandos bleibt das Reading  "ServiceOn" auf no. Der Antrieb zeigt auch keinerlei Reaktion.

Interessehalber habe ich 10_EnOcean.pm um das SummerBit des MD15 ergänzt und getestet. Das Setzen des SummerBit durch Fhem hat ebenfalls keine Auswirkungen. Ich weiß jedoch, dass mein MD15 das SummerBit grds. akzeptiert; zumindest mit meiner Closed-Source-Software. Die Maintance Mode-Funktionen bietet meine Closed-Source-Software nicht, daher habe ich dort keinen Vergleich.

Gemeinsamkeit des SummerBit und der Servicefunktionen ist laut Anleitung: "Diese Funktion bedarf eines geeigneten Funkpartners, der die Funktion unterstützt." Was auch immer das heißen mag!?
http://www.loxone.com/tl_files/loxone/downloads/datasheets/DE/200067_Funk_Stellantrieb.pdf

Hat irgendwer die Maintance Mode Funktionen erfolgreich getestet?

klaus.schauer

Bisher habe keine Rückmeldungen dazu erhalten, leider. Bitte beachten, dass die Befehle erst gesendet werden, nachdem Fhem ein  Telegramm vom Ventil erhalten hat. Es kann also manchmal 10 min dauern!

krikan

#2
Die 10 min und testweise bis zu 30 min hatte ich beachtet. Es hat aber keine Änderungen/Besserungen bewirkt. "SerivceOn" bleibt immer no und keine Reaktion des Stellantriebs.

Kennst Du den Grund, warum $subDef = "00000000"  in Funtion EnOcean_hvac_01Cmd($$$) ist?

klaus.schauer

Dies stammt aus der allerersten Implementierung des Profils. Mit 00000000 wird die ChipID gesendet. Eigentlich wäre eine SenderID aus dem Adresspool sinnvoller. Ich habe das Profil bisher nur ganz vorsichtig weiterentwickelt. Es kamen einfach keine Rückmeldungen.

krikan

Ok, probiere dann mal eine andere SenderId/ChipID -auch beim Tech-In- zu nutzen. Vielleicht ändert das ja etwas. Mich irritiert insbesondere, dass auch das SummerBit nicht funktioniert.

ZitatEs kamen einfach keine Rückmeldungen.

Tja, liegt auch an mir  :-[ .  Hatte ich dir eigentlich vor mehr als einem Jahr zugesagt. Aber ich arbeite daran.....

klaus.schauer

Ich denke nicht, dass es an der SenderID liegt.

krikan

Habe jetzt erstmal nicht die SenderId geändert. Vielmehr habe ich Teach-In und Steuerung des MD15 durch Fremdsoftware mitgeloggt. Anschließend das Ganze auch mit leicht angepasstem Fhem. Konzentriert habe ich mich auf das SummerBit, was mich besonders interessiert (Reduzierung der Telegramme von alle 10 auf alle 30min).

Nach Durchsicht der angehängten Logs verstehe ich momentan nichts mehr. Zumindest in Datenteil der Telegramme, die für die Sommermodus-Steuerung zuständig sind (DB0 und DB1) sind keine Abweichungen festzustellen. Jedoch funktioniert es mit Fhem nicht, aber mit dem anderen Produkt schon. Woran kann es jetzt noch liegen? Teach-In oder andere Bestandteile des Telegramms?

Vielleicht hat noch jemand (Klaus? ;)) Ideen oder sieht das Problem auf einen Blick.

Um das SummerBit in Fhem zu berücksichtigen, habe ich 10_EnOcean.pm anpassen müssen: Neues Attribut "summerMode". Die anpasste Version ist angehängt (Achtung: Enthält auch PSC234-Anpassungen). Habe ich vielleicht bei meinen Trial-And-Error-Codeanpassungen etwas falsch eingebaut?

krikan

Es liegt an der SenderId.

Nach Änderung von subDef auf eine SenderId des Adresspools funktioniert der "summerMode". Der MD15 braucht also ein Teach-In mit einer SenderId.

Bei meinen Test hatte ich ein Problem mit der Funktion EnOcean_CheckSenderID($$$) GetNextId. Beim bidi-Teach-In liefert der Aufruf der Funktion anscheinend immer subDef="00000000" zurück. Alle bidi-Teach-Ins erhalten automatisch dieses subDef und kein subDef aus des Adresspool. Ursache ist mir unklar.

klaus.schauer

#8
Ich habe die Vergabe der SenderID umgebaut. Hierzu die überarbeiteten Dateien mit diversen anderen Neuerungen und Änderungen, z. B.
- für Permundo SmartPlug (Energieanzeige, Abfangen der MSC-Telegramme)
- PTM 215 Verschlüsselung
- Sendetiming für die TCM Transceiver
- SenderID für MD15 Stellantrieb
- usw.

Eine Liste und Beschreibung der Neuerungen und Änderungen ist leider noch nicht fertig. Bitte die Funktionen testen, danke.

Wichtig: 00_TCM und 10_EnOcean müssen gleichzeitig ausgetauscht werden.

krikan

Danke! Wäre schön, wenn Du den SummerMode (SummerBit) für den MD15 noch ergänzen könntest.

krikan

Hallo Klaus,

folgende Probleme habe ich im Kurztest leider:

  • subDef wird beim bidi-Teach-In bei mir immer noch überall mit "0000000" vorbelegt (getestet am PSC234 und MD15)
  • get measurement aktualisiert die Readings in der Detailansicht nicht (getestet mit bek. Peha und PSC234); keine Ahnung, ob das an Deinen Änderungen oder anderen Ändernungen in Fhem liegt

Gruß, Christian

klaus.schauer

Die SenderIDs werden nur aus dem Adresspool ausgewählt, falls der Adressbereich beim Fhem-Start richtig aus dem Transceiver ausgelesen wurde. Bitte die Einträge des TCM-Devices prüfen. Ich habe nur beim MD15 die Adresszuweisung aktualisiert. UTE ist unverändert!

Die Aktualisierung von Readings wurde nicht verändert

krikan

ZitatBitte die Einträge des TCM-Devices prüfen.

Für mich sieht das in Ordnung aus:

Internals:
   BaseID     FFAEEE80
   DEF        310 /dev/ttyUSB3@57600
   DeviceName /dev/ttyUSB3@57600
   FD         40
   LastID     FFAEEEFF
   MODEL      ESP3
   NAME       TCM310_3
   NR         152
   NTFY_ORDER 50-TCM310_3
   PARTIAL
   RSSI       -77
   STATE      initialized
   TYPE       TCM
   Readings:
     2014-05-30 19:02:46   baseID          BaseID: FFAEEE80 RemainingWriteCycles: 0A
     2014-05-29 22:22:18   idbase          BaseID=FFAEEE80,RemainingWriteCycles=0A
     2014-05-30 19:02:50   maturity        01
     2014-05-22 18:56:10   numSecureDev    NOT_SUPPORTED
     2014-05-22 18:56:16   repeater        repEnable=00,repLevel=01
     2014-05-30 19:02:50   state           initialized
     2014-05-22 18:56:57   sw_ver          APIVersion=02020200,APPVersion=02040000,ChipID=01035DDD,ChipVersion=454F0103,Desc=GATEWAYCTRL
     2014-05-27 21:53:06   version         APIVersion=02020200,APPVersion=02040000,ChipID=01035DDD,ChipVersion=454F0103,Desc=GATEWAYCTRL
Attributes:
   sendInterval 0


Hast Du Vorschläge, was zu unternehmen ist!?

ZitatDie Aktualisierung von Readings wurde nicht verändert
Ok, dann liegt es irgendwo anders...

klaus.schauer

Hier mein Ergebnis vom PEHA 452 FU-EBIM Testgerät:


Internals:
   CFGFN
   DEF        FF80F781
   IODev      TCM_0
   LASTInputDev TCM_0
   MSGCNT     21
   NAME       EnO_UTE_FF80F781
   NOTIFYDEV  global
   NR         604
   STATE      off
   TCM_0_DestinationID FFFFFFFF
   TCM_0_MSGCNT 21
   TCM_0_PacketType 1
   TCM_0_RSSI -65
   TCM_0_ReceivingQuality excellent
   TCM_0_RepeatingCounter 0
   TCM_0_SubTelNum 3
   TCM_0_TIME 2014-05-30 21:30:33
   TYPE       EnOcean
   Readings:
     2014-05-30 21:30:33   channel0        off
     2014-05-30 21:29:00   channelAll      off
     2014-05-30 21:30:33   dim             0
     2014-05-30 21:30:33   dim0            0
     2014-05-30 21:30:33   energy0         0
     2014-05-30 21:30:33   energyUnit0     KWh
     2014-05-30 21:30:33   error0          ok
     2014-05-30 21:30:33   localControl0   enabled
     2014-05-30 21:30:33   overCurrentOff0 ready
     2014-05-30 21:30:33   power0          0
     2014-05-30 21:30:33   powerFailure0   disabled
     2014-05-30 21:30:33   powerFailureDetection0 not_detected
     2014-05-30 21:30:33   powerUnit0      W
     2014-05-30 21:30:33   state           off
     2014-05-30 21:27:30   teach-in        EEP D2-01-08 Manufacturer: Peha
Attributes:
   IODev      TCM_0
   comMode    biDir
   defaultChannel 0
   devChannel FF
   manufID    001
   room       EnOcean
   subDef     FFFCF30D
   subType    actuator.01


Ein MD15 kann ich leider nicht testen.

krikan

Habe Fritzbox mit Fhem neu gestartet. Kontrolliert, ob wirklich Deine neuen Module installiert sind.
TCM-Base-Id scheint korrekt gelesen zu sein:
BaseID: FFAEEE80 RemainingWriteCycles: 0A   2014-05-30 21:42:5

MD15 neu angelernt.
subDef ist automatisch wieder "00000000"
PSC234 neu angelernt.
subDef ist automatisch wieder "00000000"

Keine Ahnung, was ich falsch mache. Bin derzeit ratlos.

Peha kann/will ich Teach-In wegen Familienfriedens nicht testen, da der in der richtigen Installation läuft.

krikan

#15
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

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

#17
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

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

krikan

#19
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:
2014.06.01 12:43:26 5: SW: 55000A0701EBA582700408000301000EFAFF002F

Richtig wäre folgende Form:
2014.05.30 11:20:20 5: SW: 55000A0701EBA5826B0C08FFAEEE82000301000EFAFF00CE

List ergibt:

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:
my $subDef = ReadingsVal($name, "subDef", undef);
Sonst hast Du per AttrVal zugewiesen.

Gruß, Christian


edit: Codezeile korrigiert

klaus.schauer

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

krikan

Habe Zeile 4065 in 10_EnOcean.pm ausgetauscht gegen:
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

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

krikan

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:

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

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

krikan

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

krikan

#26
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

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

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

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.

klaus.schauer

Den Sinn der Funktion initialize kann ich augenblicklich auch nicht erkennen, wenn man sich das gesendete Telegramm betrachtet. Ich denke das Kommando kann entfallen.

Wurde mit der ChipID oder einer Adresse aus dem Adresspool getestet?

Sind die Anzeigen des Permondo Schalters jetzt in Ordnung?

krikan

ZitatIch denke das Kommando kann entfallen.
Sehe ich genauso.

ZitatWurde mit der ChipID oder einer Adresse aus dem Adresspool getestet?
Adresse aus Adresspool, da diese Voraussetzung für Service-Funktionen und sommerMode ist. Mit ChipId sind nur die Grundfunktionen (set actuator und set desired-temp) möglich.

ZitatSind die Anzeigen des Permondo Schalters jetzt in Ordnung?
Seit dem 03.06. keine Probleme festgestellt; selbst "dim" wird richtig gesetzt

Habe insgesamt keine Probleme in den letzten 3 Tagen festgestellt.

Vielen Dank an Dich, Klaus, für Deine Arbeit an den Modulen!


klaus.schauer

Die Probleme beim Fhem-Start sollten jetzt auch beseitigt sein, siehe Erläuterungen zu 10_EnOcean V6001.

Jochen Auer

Schönen guten Tag,

ich habe eine Frage zum einlernen des MD15
wenn ich den Antrieb wie bisher einlerne ist die subDef immer noch "00000000".
wenn ich nun die subDef ändere auf meine BaseID von meinem TCM, geht der Stellanrieb nicht mehr!

Mach ich jetzt beim einlernen was falsch oder wo ist mein Fehler? Ich möchter gerne den SummerMode nutzen und dieses geht ja anscheinend nur wenn eine BaseID eingetragen wurde!

Grüße
Jochen

krikan

#34
Hallo Jochen,

subDef muss nicht auf BaseID geändert werden. Vielmehr musst Du mit einer freien SenderID als subDef einlernen, damit der summerMode funktioniert. Beim Teach-In sollte die nächste freie SenderId vergeben werden. Es könnte sein, dass Du über das gleiche Problem beim Teach-IN stolperst, wie ich unter http://forum.fhem.de/index.php/topic,24685.0.html beschrieben habe.

Gruß, Christian

(edit)
Vermutlich funktionierende Notlösung: In 10_EnOcean.pm Zeile 2424 ersetzen durch $subDef = "Deine nächste freie SenderId" und teach-In durchführen. Anschließend Original 10_EnOcean.pm wieder einspielen.

Jochen Auer

Hi Christian,

danke für deinen schnell Tip.
Jetzt ging es den Aktor einzulernen, leider musste ich dazu die 10_EnOcean.pm ändern wie du es beschrieben hast!