Hallo,
was ist falsch eingestellt wenn ich als STATE "Manufacturer Specific Application unknown" beim Ende der Fahrt oder beim Stop bekomme?
Rollo hat einen STATE beim Runterfahren: AI released
fhem.cfg
define Rollo_AZ EnOcean 0088xxxx
attr Rollo_AZ alias Jalousie AZ
attr Rollo_AZ devStateIcon B0.*:shutter_open BI.*:shutter_closed
attr Rollo_AZ eventMap down:Ab up:Auf stop:Stop
attr Rollo_AZ manufID 00D
attr Rollo_AZ model FSB61
attr Rollo_AZ room Jalousie
attr Rollo_AZ shutTime 33
attr Rollo_AZ shutTimeCloses 33
attr Rollo_AZ subDef FFCEFxxx
attr Rollo_AZ subType manufProfile
attr Rollo_AZ webCmd Auf:Ab:Stop
define FileLog_Rollo_AZ FileLog ./log/Rollo_AZ-%Y.log Rollo_AZ
attr FileLog_Rollo_AZ logtype text
attr FileLog_Rollo_AZ room hidden
define Rollo_AZ_sensor EnOcean FFCEFxxx
attr Rollo_AZ_sensor manufID 00D
attr Rollo_AZ_sensor subType A5.3f.7F
#attr Rollo_AZ_sensor subType sensor
define FileLog_Rollo_AZ_sensor FileLog ./log/Rollo_AZ_sensor-%Y.log Rollo_AZ_sensor
attr FileLog_Rollo_AZ_sensor logtype text
attr FileLog_Rollo_AZ_sensor room hidden
fhem log
2013.06.16 15:36:05 5: TCM310_0/RAW: 55000A0701EBA5014A010A0088xxxx01
2013.06.16 15:36:05 5: TCM310_0/RAW: 55000A0701EBA5014A010A0088xxxx0101FFFFFFFF3D0088
2013.06.16 15:36:05 5: TCM310_0 dispatch EnOcean:1:A5:014A010A:0088xxxx:01:01FFFFFFFF3D00
2013.06.16 15:36:05 4: EnOcean: Rollo_AZ PacketType: 1 RORG:A5 DATA:014A010A ID:0088xxxx STATUS:01
2013.06.16 15:36:05 5: Triggering Rollo_AZ (1 changes)
2013.06.16 15:36:05 5: Notify loop for Rollo_AZ Manufacturer Specific Application unknown
Gruß Otto
Zitat von: Otto schrieb am So, 16 Juni 2013 15:44Hallo,
was ist falsch eingestellt wenn ich als STATE "Manufacturer Specific Application unknown" beim Ende der Fahrt oder beim Stop bekomme?
Rollo hat einen STATE beim Runterfahren: AI released
fhem.cfg
define Rollo_AZ EnOcean 0088xxxx
attr Rollo_AZ alias Jalousie AZ
attr Rollo_AZ devStateIcon B0.*:shutter_open BI.*:shutter_closed
attr Rollo_AZ eventMap down:Ab up:Auf stop:Stop
attr Rollo_AZ manufID 00D
attr Rollo_AZ model FSB61
attr Rollo_AZ room Jalousie
attr Rollo_AZ shutTime 33
attr Rollo_AZ shutTimeCloses 33
attr Rollo_AZ subDef FFCEFxxx
attr Rollo_AZ subType manufProfile
attr Rollo_AZ webCmd Auf:Ab:Stop
define FileLog_Rollo_AZ FileLog ./log/Rollo_AZ-%Y.log Rollo_AZ
attr FileLog_Rollo_AZ logtype text
attr FileLog_Rollo_AZ room hidden
define Rollo_AZ_sensor EnOcean FFCEFxxx
attr Rollo_AZ_sensor manufID 00D
attr Rollo_AZ_sensor subType A5.3f.7F
#attr Rollo_AZ_sensor subType sensor
define FileLog_Rollo_AZ_sensor FileLog ./log/Rollo_AZ_sensor-%Y.log Rollo_AZ_sensor
attr FileLog_Rollo_AZ_sensor logtype text
attr FileLog_Rollo_AZ_sensor room hidden
fhem log
2013.06.16 15:36:05 5: TCM310_0/RAW: 55000A0701EBA5014A010A0088xxxx01
2013.06.16 15:36:05 5: TCM310_0/RAW: 55000A0701EBA5014A010A0088xxxx0101FFFFFFFF3D0088
2013.06.16 15:36:05 5: TCM310_0 dispatch EnOcean:1:A5:014A010A:0088xxxx:01:01FFFFFFFF3D00
2013.06.16 15:36:05 4: EnOcean: Rollo_AZ PacketType: 1 RORG:A5 DATA:014A010A ID:0088xxxx STATUS:01
2013.06.16 15:36:05 5: Triggering Rollo_AZ (1 changes)
2013.06.16 15:36:05 5: Notify loop for Rollo_AZ Manufacturer Specific Application unknown
Gruß Otto
Ich kann den Fehler bei mir nicht nachstellen?! Die Stati bei der Rollosteuerung werden richtig angezeigt.
Ich verstehe nicht, wozu der Sensoreintrag benötigt wird:
define Rollo_AZ_sensor EnOcean FFCEFxxx
attr Rollo_AZ_sensor manufID 00D
attr Rollo_AZ_sensor subType A5.3f.7F
#attr Rollo_AZ_sensor subType sensor
define FileLog_Rollo_AZ_sensor FileLog ./log/Rollo_AZ_sensor-%Y.log Rollo_AZ_sensor
attr FileLog_Rollo_AZ_sensor logtype text
attr FileLog_Rollo_AZ_sensor room hiddenWeiterhin gibt es keinen subtype
A5.3f.7F, sondern einen subtype manufProfile mit der EEP A5-3F-7F. Zu dem dieses Profil gehört der Sensor Thermokon SR65 3AI. Thermokon hat die manufID 002. Gibt es diesen Sensor nun auch von Eltako mit der Eltako manuID 00D? Wurde der Eintrag manuell oder eventuell durch Fhem automatisch eingelegt? Falls möglich, bitte mal den Sensoreintrag komplett entfernen.
Beim Profil für den Thermokon SR65 3AI gibt es die Fehlermeldung "Manufacturer Specific Application unknown", falls die manufID nicht 002 ist! D. h. die Fehlermeldung kann es auch nur beim "Rollo_AZ_sensor" geben... hoffentlich.
Hallo Klaus,
dieser Sensoreintrag wir von FHEM automatisch angelegt, löschen geht also nicht.
define EnO_sensor_FFCEFxxx EnOcean FFCEFxxx
attr EnO_sensor_FFCEFxxx room EnOcean
attr EnO_sensor_FFCEFxxx subType sensor
define FileLog_EnO_sensor_FFCEFxxx FileLog ./log/EnO_sensor_FFCEFxxx-%Y.log EnO_sensor_FFCEFxxx
attr FileLog_EnO_sensor_FFCEFxxx logtype text
attr FileLog_EnO_sensor_FFCEFxxx room EnOcean
habe noch 4 andere Eltako FSB61, da geht es auch mit dem "Sensoreintrag"
Gruß Otto
Zitat von: Otto schrieb am So, 16 Juni 2013 21:19Hallo Klaus,
dieser Sensoreintrag wir von FHEM automatisch angelegt, löschen geht also nicht.
define EnO_sensor_FFCEFxxx EnOcean FFCEFxxx
attr EnO_sensor_FFCEFxxx room EnOcean
attr EnO_sensor_FFCEFxxx subType sensor
define FileLog_EnO_sensor_FFCEFxxx FileLog ./log/EnO_sensor_FFCEFxxx-%Y.log EnO_sensor_FFCEFxxx
attr FileLog_EnO_sensor_FFCEFxxx logtype text
attr FileLog_EnO_sensor_FFCEFxxx room EnOcean
habe noch 4 andere Eltako FSB61, da geht es auch mit dem "Sensoreintrag"
Gruß Otto
Die Quittungstelegramme der FSB61, die beim ersten Senden automatisch einen Eintrag erzeugen, sind vom Typ "switch" (RORG F6, ORG 05).
Ich habe eine ganz andere Vermutung. Die Sensoreinträge sind Fhem-Telegramme, die von einem Repeater gesendet und wieder von Fhem empfangen wurden. Jedenfalls scheinen die Adressen FFCEFxxx aus dem Bereich des TCM-Moduls zu sein und nicht von den FSB61.
Im TCM-Modul kann man die Weiterverarbeitung von Telegrammen mit eigenen SenderIDs blockieren. Mal
attr TCM310_0 blockSenderID own eintragen und die Sensoreinträge aus der fhem.cfg löschen. Vielleicht ist es auch möglich, auf Repeater zu verzichten. Ich würde Repeater nur einsetzen, wenn es unbedingt nötig ist.
Zitat von: klaus.schauer schrieb am So, 16 Juni 2013 22:17Die Quittungstelegramme der FSB61, die beim ersten Senden automatisch einen Eintrag erzeugen, sind vom Typ "switch" (RORG F6, ORG 05).
Ich habe eine ganz andere Vermutung. Die Sensoreinträge sind Fhem-Telegramme, die von einem Repeater gesendet und wieder von Fhem empfangen wurden. Jedenfalls scheinen die Adressen FFCEFxxx aus dem Bereich des TCM-Moduls zu sein und nicht von den FSB61.
Im TCM-Modul kann man die Weiterverarbeitung von Telegrammen mit eigenen SenderIDs blockieren. Mal
attr TCM310_0 blockSenderID own
eintragen und die Sensoreinträge aus der fhem.cfg löschen. Vielleicht ist es auch möglich, auf Repeater zu verzichten. Ich würde Repeater nur einsetzen, wenn es unbedingt nötig ist.
Die Sensoren mit subType A5.3f.7F werden meiner Erfahrung nach angelegt wenn man eine subDef vergibt, jedoch keinen passenden Eintrag in der FHEM.cfg anlegt. Beim teach in legt FHEM dann einen Eintrag wie diesen an
define XXX EnOcean FFA*****
attr XXX manufID 00D
attr XXX subType A5.3f.7F
Der "falsche" subType stört aber die Funktion, zumindest bei meinem test, nicht.
Zitat von: gaggi schrieb am Mo, 17 Juni 2013 09:18Zitat von: klaus.schauer schrieb am So, 16 Juni 2013 22:17Die Quittungstelegramme der FSB61, die beim ersten Senden automatisch einen Eintrag erzeugen, sind vom Typ "switch" (RORG F6, ORG 05).
Ich habe eine ganz andere Vermutung. Die Sensoreinträge sind Fhem-Telegramme, die von einem Repeater gesendet und wieder von Fhem empfangen wurden. Jedenfalls scheinen die Adressen FFCEFxxx aus dem Bereich des TCM-Moduls zu sein und nicht von den FSB61.
Im TCM-Modul kann man die Weiterverarbeitung von Telegrammen mit eigenen SenderIDs blockieren. Mal
attr TCM310_0 blockSenderID own
eintragen und die Sensoreinträge aus der fhem.cfg löschen. Vielleicht ist es auch möglich, auf Repeater zu verzichten. Ich würde Repeater nur einsetzen, wenn es unbedingt nötig ist.
Die Sensoren mit subType A5.3f.7F werden meiner Erfahrung nach angelegt wenn man eine subDef vergibt, jedoch keinen passenden Eintrag in der FHEM.cfg anlegt. Beim teach in legt FHEM dann einen Eintrag wie diesen an
define XXX EnOcean FFA*****
attr XXX manufID 00D
attr XXX subType A5.3f.7F
Der "falsche" subType stört aber die Funktion, zumindest bei meinem test, nicht.
Das finde ich recht merkwürdig. Vielleicht kann man das Verhalten reproduzierbar nachstellen. Ich sehe im Augenblick nicht, an welcher Stelle man bei der Fehlersuche ansetzen könnte.
Ist absolut reproduzierbar.
An einem von FHEM automatisch erkanntem FSB61 (FHEM erstellt bei mir durch das einstellen der Fahrzeit an einem davor montiertem Taster einen switch) einfach subType und manufID richtig setzen und eine subDef vergeben. Dann den FSB61 in den Lernmodus versetzen und mit "set device teach" einlernen und schon erstellt dir autocreate ein device mit dem subType A5.3f.7F.
Zitat von: gaggi schrieb am Mo, 17 Juni 2013 12:32Ist absolut reproduzierbar.
An einem von FHEM automatisch erkanntem FSB61 (FHEM erstellt bei mir durch das einstellen der Fahrzeit an einem davor montiertem Taster einen switch) einfach subType und manufID richtig setzen und eine subDef vergeben. Dann den FSB61 in den Lernmodus versetzen und mit "set device teach" einlernen und schon erstellt dir autocreate ein device mit dem subType A5.3f.7F.
Bis zum senden des teach-Telegrams ist ja alles ok. Aber das danach kann eigentlich nicht sein. Wenn nicht Fhem für sein eigenes teach Telegramm, das über einen Repeater zurückkommt ein neues Devices anlegt.
Deshalb auch hier die Frage: Sind Repeater im Einsatz? Falls ja, könnte man mal das Verhalten ohne Repeater untersuchen und alternativ die Empfangssperre attr <TCM> blockSenderID own setzen.
Du hast natürlich vollkommen recht, es war wirklich das teachin Telegramm, dass von einem Repeater zurückgeworfen wurde.
Mit blockSenderID own wird kein Device mehr angelegt.