Eltako FAS260SA Funk-Außensirene

[Flachzange]

Hallo zusammen,

hat hier schon mal jemand eine FAS260SA Funk-Außensirene in Betrieb genommen? Neuerdings Eltako-typisch nutzen sie MSC-Telegramme, die auch nicht dokumentiert sind. Oder ich habe sie einfach noch nicht gefunden.

Autocreate in FHEM macht nicht so wahnsinnig viel. Es wird ein Gerät angelegt mit dem subtype "SMLRNREQ".

Gruß
Chris

[Flachzange]

Ok, ich hätte vermutlich selbst darauf kommen können, dass SMLRNREQ für SmartAckLearning Request steht. Also mit SmartAckLearning eingelernt und Gerät wird samt Postmaster angelegt. Hier habe ich noch einen Bug, dass das falsche TCM als IODev genommen wird, obwohl assingIODev auf no steht. Korrigiere ich das händisch bekomme ich die Sirene in den Modus Alarmbereitschaft aktiv und sie sendet zyklisch alle 3 Sekunden. Diese Nachricht empfange ich aber nur auf meinen anderen TCM, nicht auf dem TCM über das er eingelernt wurde. Jedenfalls zeigt mir das Log diese Nachrichten nicht an.

Mit den Infos von Eltako habe ich dann noch folgende Daten zu den Telegrammen:

0x0100000C (off lock): Alarm und Alarmbereitschaft deaktiviert/ Alarmfunktion für zyklische Telegrammüberwachung außer
Betrieb/ Sirene verstummt

0x01000009 (on): Alarm aktiv/ Sirene ertönt für die eingestellte Zeit (Jumper).

0x01000008 (off): Alarmbereitschaft aktiviert / Telegrammüberwachung in der Sirene aktiv/ Bei einer Kommunikationstörung meldet sich die Sirene z.B. durch zwei akustische Impulse.

Leider kamen auch diese Befehle nicht an der Sirene an. Ich habe mich dann an mein letztes Projek den F4CT55 erinnert und mal gemäß Trial & Error die destinationID auf die ID der FAS260SA gesetzt und zack klappt es auch mit den set-Befehlen.

[Flachzange]

Wie schon zuvor beobachtet stimmt noch etwas nicht beim SmartAckLearn in Kombination mit mehreren TCM.

Ich habe insgesamt drei TCM (TCM 1-3). TCM1 hat assignIODev=yes, TCM2+3 haben assignIODev=no

Die FAS260SA soll in TCM3 eingelernt werden. Zu Beginn hat keines der TCM einen Postmaster-Client.

• set TCM3 smartAckLearn 30
• Lerntaste am Gerät drücken
• Gerät wird über autocreate angelegt. Iodev ist TCM1. Bei keinem TCM wurde ein PostmasterClient angelegt
• FAS260SA ist nicht steuerbar

Lösung (Gerät nicht löschen):

• iodev auf TCM3 setzen
• set TCM3 smartAckLearn 30
• Lerntaste am Gerät drücken
• PostmasterClient wird für TCM3 angelegt
• FAS260SA ist steuerbar

@Klaus: Mache ich noch etwas falsch oder gibt es da einen der Bug in der Anlernroutine?

[klaus.schauer]

Beim smartAckLearn wird der Parameter assignIODev vermutlich nicht berücksichtigt. Ich habe das aber noch nicht prüfen können.

Geräte die smartAck verwenden, sind absolute Exoten. Die Kombination mit einem System mit mehreren Transceivern wird das noch exotischer. Da landet sowas bei mir bedauerlicherweise auf der To-Do-Liste ganz unten, sorry.

[Flachzange]

Kein Problem. Ich bin auch immer wieder überrascht, in welche Edge Cases man reinlaufen kann.

[Damu]

Ich hab das so verstanden das mann nur mit dem Controller anlernt der "assignIODev yes" ist.

Das heisst "set TCM1 smartAckLearn 30"

Oder geht das auch anders?

Ich lerne die alles immer mit dem Controller 1 an.
Und setze das Attribut "IODev" im Device, immer auf den Controller der dem Device am nächsten ist.
   

[Flachzange]

Bei einem normalem "set TCM teach xx" wird ein device per autocreate angelegt und es wird das TCM als iodev gesetzt, welches sich im Lernmodus befunden hat also für die Anlage des Gerätes verantwortlich war. Das habe ich gerade nochmal getestet. Dann kann ich natürlich im Nachgang das iodev auf etwas anderes setzen, z.b., auf das TCM, das näher dran ist. Das funktioniert aber nur, wenn der Anlernvorgang nicht bidirekational war, denn ansonsten spricht das Gerät ggf. ja nur mit dem ersten TCM. Anders ist es, wenn autocreate nur die "Hülle" angelegt hat und man in FHEM noch ein "set Device teach" machen muss, z.B. Eltako Tipp-Funk-Geräte. set teach greift dann auf das hinterlegte iodev zurück.

Das ist aus meiner Sicht auch deckungsgleich mit der Commandref, die ja von "manual setup" spricht.

Within an Fhem installation with multiple transceivers, one of these transceivers sends the outgoing telegrams. The transceiver is assigned to IODev when an EnOcean device is set up. One of the enabled transceivers can be specifically selected as the transmitting device (IODev) for manual setup of EnOcean devices. For this purpose, the attribute

    attr <name> assignIODev yes

must be set.

[Damu]

Sorry wenn ich hier weiterschreibe.
Das verstehe ich nicht ganz, hab es (leider) gar nicht mit dem Englich.

Das heist ich kann auch mit dem TCM310 Anlernen das nicht (attr TCM310_x assignIODev yes) ist?

Gibt es Probleme wenn ich das (attr TCM310_x assignIODev yes/no) für das Anlernen umstelle, und wenn das Device angelernt ist und geht, wieder zurück ändere?

Hab noch nicht so viele Devices, hab das IODev am Device nach dem Anlernen immer richtiggestellt.

[Flachzange]

Das heist ich kann auch mit dem TCM310 Anlernen das nicht (attr TCM310_x assignIODev yes) ist?

Der Anlernvorgang (set <TCM> teach xx) ist unabhängig von assignIODev. Du kannst jedes TCM in den Lernmodus versetzen. Danach sollte automatisch IODev auf genau dieses TCM gesetzt sein (siehe vorheriger Beitrag). Das Attribut assignIODev dient in erster Linie dazu ein Default-IODev zu setzen, wenn ein EnOcean-Device manuell angelegt wird, also nicht über "set <TCM> teach xx"

Gibt es Probleme wenn ich das (attr TCM310_x assignIODev yes/no) für das Anlernen umstelle, und wenn das Device angelernt ist und geht, wieder zurück ändere?

Es hängt von der konkreten Anlernprozedur ab. Und nur um Sicherzugehen: Es ist nur für Aktoren relevant, die auch auf Nachrichten von FHEM reagieren. Für diese wird ja in der Regel ein subDef festgelegt (eine SendeID aus der Range des zugewiesenen TCM, also das was bei IODev steht). Bei einem bidirektionalen Anlernvorgang wird dieses möglicherweis direkt festgelegt und FHEM und Aktor können sich unterhalten. Wenn Du jetzt im Nachgang das IODev änderst passt die ID aus subDef nicht mehr zur BaseID des dann neu zugewiesenen TCM.

Wenn es noch nicht klar ist, nenn am besten mal ein echtes Beispiel-Gerät und beschreib, wie Du es einlernst.

[Damu]

Hab die selbe BaseID an beiden Gateway.
Muss das dann mal nachschauen.

[Flachzange]

Interessant. Ohne dass ich es jetzt argumentativ begründen könnte, hätte ich vermutet, dass das an irgendeiner Stelle kaputt geht.

[Damu]

Hab nachgeschaut, habe bei beiden IODev die selbe BaseID gesetzt.
Habe das Irgend nach einer Anleitung eingerichtet, finde das aber nicht mehr.

Bei der Kontrolle ist mir aufgefallen das es SenderID gab die zweimal vergeben wurden.
War bei Stellantrieben manschmal so.
Wie grenze ich einmal vergebene SenderID aus, das Sie nicht zweimal vergeben werden?
Ich möchte das mal so lassen und schauen ob es wirklich Probleme gibt.

[Flachzange]

Wie grenze ich einmal vergebene SenderID aus, das Sie nicht zweimal vergeben werden?

Das ist ja das Problem, wenn beide TCM die gleiche BaseID haben. Jedes TCM für sich stellt sicher, dass seine eigenen SenderIDs nur einmal vergeben wurden. Über TCMs hinweg geht das dann nicht mehr.

[Damu]

Habe wieder bei alle Devices (mit einem BaseID vom TCM) das TCM1 als IODev gesetzt.
Bei den Sensoren sollte es doch keine Rolle spielen?
Vergibt das TCM oder FHEM die BaseID?

[Flachzange]

Die SenderIDs sind nur für Aktoren relevant, die Du mit FHEM steuern möchtest. Für Sensoren nicht relevant.

Du vergibst die BaseID via FHEM, was Du ja scheinbar auch gemacht hast, weil sie sonst nicht gleich wären.

baseID [FF000000 ... FFFFFF80]
Set the BaseID.
Note: The firmware executes this command only up to then times to prevent misuse.

Also Achtung. Das geht nur maximal 10 mal, bei dir noch maximal 9 mal.

Danach musst Du bei allen Aktoren die SenderID neu erstellen mit "getNextID" und FHEM neu in die Aktoren einlernen. Du solltest also ggf. die BaseID des TCM ändern, welches in den wenigsten Aktoren eingelernt ist.