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?
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!
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?
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.
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.....
Ich denke nicht, dass es an der SenderID liegt.
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?
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.
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.
Danke! Wäre schön, wenn Du den SummerMode (SummerBit) für den MD15 noch ergänzen könntest.
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
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
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...
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.
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.
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?
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?
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.
attr summerMode off|on für MD15 ist jetzt auch verfügbar. Bitte testen.
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
War natürlich ein Fehler. Habe ich geändert. Danke für den Hinweis. Ich hoffe es passt jetzt.
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.
Hier die Fassung der Dateien, die ich alsbald verteilen wollte.
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
10_TCM ist unverändert. Die neue 10_EnOcean läuft bei mir problemlos auf der FRITZ!Box 7490 und Raspberry PI.
Dann verstehe ich es nicht. Werde noch mal schrittweise und in Ruhe alles durchgehen. Komme dazu aber erst im Laufe der Woche.
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.
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.
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
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.
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?
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!
Die Probleme beim Fhem-Start sollten jetzt auch beseitigt sein, siehe Erläuterungen zu 10_EnOcean V6001.
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
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.
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!