STATE: Manufacturer Specific Application unknown

[Otto]

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

Code: [Auswählen]


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

Code: [Auswählen]

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

[klaus.schauer]

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

Code: [Auswählen]


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

Code: [Auswählen]

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:

Code: [Auswählen]

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

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

[Otto]

Hallo Klaus,

dieser Sensoreintrag wir von FHEM automatisch angelegt, löschen geht also nicht.

Code: [Auswählen]

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

[klaus.schauer]

Hallo Klaus,

dieser Sensoreintrag wir von FHEM automatisch angelegt, löschen geht also nicht.

Code: [Auswählen]

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.

[gaggi]

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.

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.

[klaus.schauer]

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.

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.

[gaggi]

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.

[klaus.schauer]

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.

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.

[gaggi]

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.