FMS61 Kanal A schaltet andere Devices

[Eisix]

Hallo,

kurz das Szenario. Habe einen Elektroheizer mit zwei Stufen den ich über einen FMS61 ansteuere.
Anlernen nach Wiki was auch funktioniert. Dann ist mir aufgefallen das der Kanal A andere Geräte mit schaltet. Sprich wenn meine Heizung auf die zweite Stufe schaltet gehen mehrere andere Geräte aus (AI und A0 sind beim FMS61 andersrum).
Ich habe den FMS61 schon mit eigener Sende ID angelegt oder auch keine angegeben was zu einer automatischen Vergabe führen sollte. Auch ein anderer FMS61 brachte keine Änderung. Irgendwas stimmt nicht mit den SendeIDs denke ich, oder hat mein TCM eine Macke?

Momentan ist der FMS61 wie folgt angelegt, ohne Vergabe eine ID. Warum wurde keine automatisch angelegt?

Internals:
   CFGFN
   DEF        018EDF0E
   IODev      TCM_ESP3_0
   LASTInputDev TCM_ESP3_0
   MSGCNT     84
   NAME       Heizung_VR
   NR         103426
   NTFY_ORDER 50-Heizung_VOR
   STATE      AI
   TCM_ESP3_0_DestinationID FFFFFFFF         <--- sollte hier nicht eine individuelle für das device stehen
   TCM_ESP3_0_MSGCNT 84
   TCM_ESP3_0_PacketType 1
   TCM_ESP3_0_RSSI -79
   TCM_ESP3_0_ReceivingQuality good
   TCM_ESP3_0_RepeatingCounter 1
   TCM_ESP3_0_SubTelNum 3
   TCM_ESP3_0_TIME 2016-02-18 10:10:15
   TYPE       EnOcean
   Helper:
     Dblog:
       Buttons:
         Logdb:
           TIME       1455786615.37729
           VALUE      pressed
       Channela:
         Logdb:
           TIME       1455786615.37729
           VALUE      AI
       Channelb:
         Logdb:
           TIME       1455786083.07549
           VALUE      BI
       State:
         Logdb:
           TIME       1455786615.37729
           VALUE      AI
   Readings:
     2016-02-18 10:10:15   buttons         pressed
     2016-02-18 10:10:15   channelA        AI
     2016-02-18 10:01:23   channelB        BI
     2016-02-18 10:10:15   state           AI
   Helper:
Attributes:
   IODev      TCM_ESP3_0
   manufID    7FF                                    <--- ist die korrekt
   room       EnOcean,Vorratsraum
   subType    switch

Jemand eine Idee?

Gruss
Eisix

[krikan]

Vor längerer Zeit hatte ich es häufiger, dass die baseId beim Fhem-Start nicht ermittelt werden konnte (Bogus answer o.ä. Fehlermeldungen). Dann funktionierte auch die automatische Vergabe einer SenderId nicht.
Bei bidi-Aktoren wird die SenderId des TCMs erst beim Anlernvorgang vergeben.

[Eisix]

Solche Meldungen habe ich im LOG. Wie hast du die weg gekriegt?

2016.02.12 14:34:08 3: TCM set TCM_ESP3_0 maturity 01
2016.02.12 14:34:08 2: TCM TCM_ESP3_0 set maturity: Bogus answer received: FFFFFF52006855000100
2016.02.12 14:34:08 2: TCM TCM_ESP3_0 maturity 01 restored
2016.02.12 14:34:08 3: TCM set TCM_ESP3_0 mode 00
2016.02.12 14:34:08 2: TCM TCM_ESP3_0 set mode: Bogus answer received: 02650000550001000265
2016.02.12 14:34:08 2: TCM TCM_ESP3_0 mode 00 restored
2016.02.12 14:34:08 3: TCM get TCM_ESP3_0 baseID
2016.02.12 14:34:08 2: TCM TCM_ESP3_0 get baseID: Bogus answer received: 020E5500050102DB00FF
2016.02.12 14:34:08 3: TCM get TCM_ESP3_0 version
2016.02.12 14:34:08 2: TCM TCM_ESP3_0 get version: Bogus answer received: 9D6C000A985500
2016.02.12 14:34:08 2: TCM TCM_ESP3_0 initialized

[krikan]

Ja. Einfach Neustart oder ggfs. mal Rechner stromlos. Irgendwann war es weg. Ursache kenne ich nicht.

[Eisix]

Hab nochmal neu gestartet und die Meldung war diesmal weg. Dann lerne ich den FMS61 heute Abend neu an. Eventuell habe ich dann aber auch andere Geräte mit der falschen oder korrupten ID angelernt und deshalb werden alle gleichzeitig geschaltet.

[krikan]

Eigentlich sollte das Anlernen mit dem Problem nach meiner Erinnerung überhaupt nicht funktionieren.

TCM_ESP3_0_DestinationID FFFFFFFF         <--- sollte hier nicht eine individuelle für das device stehen

Nein. Das sollte hier so ok sein.

manufID    7FF     

Sollte hier kein Problem sein, da der FMS61 mit Tasteremulation gesteuert wird.
Eigentlich bin ich aber der Meinung man sollte immer die tatsächliche "manufID" setzen. Wenn es keine Besonderheiten für eine bestimmte manufID gibt, ist das nicht tragisch. Sollte es Besonderheiten geben, werden die dann auch berücksichtigt. Selbst, wenn diese erst mit Updates verteilt werden.

@Klaus: Ist letzteres korrekt? Soll ich eine entsprechende Empfehlung ins Wiki aufnehmen?

[Eisix]

Hab das LOG nochmal durchgeschaut und hatte nach dem Bogus Eintrag nochmal neu gestartet bevor ich den FMS61 angelernt hatte.  Anlernen hätte also normal funktionieren müssen!?

Die manufID wurde automatisch erzeugt und nicht von mir vergeben. Was ist den die richtige?

Gruß
Eisix

[krikan]

Hab das LOG nochmal durchgeschaut und hatte nach dem Bogus Eintrag nochmal neu gestartet bevor ich den FSM61 angelernt hatte.  Anlernen hätte also normal funktionieren müssen!?

Ja. Aus Deinem Eingangspost bin ich auch nicht sicher, ob Du ein Anlernproblem mit dem FMS hast oder irgendwelche notify/DOIF andere Geräte mitschalten oder ...

manufID    7FF     

7FF ist die Multi User ManufacturerId, die standardmäßig bei manueller Anlage verwendet wird.
Die Übersetzungtabelle, in der auch Eltako steht, findest Du in 10_EnOcean.pm, siehe: http://www.fhemwiki.de/wiki/EnOcean_Starter_Guide#Definition_.2F_Anlernvorgang_.28Teach-In.29 unter manufID

[Eisix]

Hab den A Kanal direkt am device mit set geschaltet und nicht über readingsProxy. Verschieden device Namen im Einsatz. Es müsst dann schon ein notify mit Wildcard sein. Bei beiden FMS61 das gleiche Verhalten. Kann eigentlich nur mit der TCM ID zusammenhängen.

[krikan]

Kann eigentlich nur mit der TCM ID zusammenhängen.

Warum? Dann müsstest Du genau diese TCM-Id an alle Aktoren angelernt haben, die beim Auslösen schalten!?
Aber vermutlich begreife ich Dein Problem nicht, warte mal ob andere Ideen kommen.

[Eisix]

Hallo,

kann mir jemand mal sagen ob mein Verständnis des Ablaufs korrekt ist:

DestinationID FFFFFFFF ---> Schaltkommando ---> Device ID ---> Bestätigungstelegramm ---> subDef

Gruß
Eisix

[krikan]

DestinationID FFFFFFFF ---> Schaltkommando ---> Device ID ---> Bestätigungstelegramm ---> subDef

Stimme ich nicht zu, da mir zu unscharf bzw. verstehe ich es evtl. falsch.
Ein wenig deutlicher, aber immer noch vereinfacht, für bidi Aktoren:
Die DestinationID in den Internals ist die "empfangene" DestinationID, wobei FFFFFFFF = multicast
Fhem schickt eine Schaltkommando mit der SenderId des TCMs aus subDef als "Absender" abhängig vom Attributwert destinationID per multicast oder unicast. Das Gerät beantwortet das mit einem Bestätigungstelegramm per multicast oder unicast (Internal) und Angabe seiner DeviceID, die in Fhem im DEF steht, als "Absender".

Btw: Wir schreiben hier doch über den FMS61 und nicht das Sendemodul FSM61 !?

[Eisix]

Hab gestern nochmal den FMS61 neu angelernt und nach ein paarmal schalten von Kanal A hat der psc234 mit angefangen zu schalten. Nach einem Reset, löschen des psc234 und neu anlernen des psc234 passierte exakt das gleiche. Dann habe ich einen zweiten psc234 probiert und auch dort das gleiche Verhalten Kanal A schaltet den psc234 mit.
Hat jemand die gleiche Kombination im Einsatz? FMS61 ist KW50/15 und die psc234 wurden dieses Jahr gekauft.
Oder jemand noch eine Idee?

@Krikan: Ja es geht um einen FMS61NP-230V 

Gruss
Eisix

[Norberto]

In Deinem device listing sehe ich kein subDef.

Du brauchst für jeden Aktor den Du schalten willst eine Sende-ID aus dem Wertebereich Deines TCM welche Du über subDef definierst.

manufID = 0x7FF ist korrekt.

Gruß, Norberto

[krikan]

Bei bidi-Aktoren wird die SenderId des TCMs erst beim Anlernvorgang vergeben.

Korrektur/Klarstellung:
Die automatische Vergabe der SenderID des TCMs funktioniert bei FMS61 bzw. Nutzung der Tasteremulation nur, wenn das Attribut subDef mit dem Wert getNextID angelegt wurde. Ein Weglassen des Attributes subDef führt während des Anlernvorgangs bei Tasteremulations nicht zur automatischen Anlage von subDef mit einer SenderID. Beim 4BS-Teach-In funktioniert die automatische Anlage von subDef mit SenderID während des Anlernvorgangs (set <device> teach), wenn man das Attribut komplett weg lässt.