Falsche Zuordnung der IODev bei Autocreate?

[duke-f]

Ich habe drei neue FS20 SI3 per autocreate meinem FHEM zugewiesen. Jetzt wurden alle hinsichtlich IODev einem falschen CUL zugewiesen, und zwar einem, der für 433 MHz ausgelegt ist. Es stimmt natürlich insofern, dass dieser CUL der letzte in der config ist. Und funktionieren tut auch alles - ich habe trotzdem IOdev auf einen der 868er-CULs geändert.

Der Text in der Commandref erscheint mir hier etwas unklar. Ist wahrscheinlich schon richtig, nur meine Lesart wird verdreht sein.

Setzt das IO oder das physische Device, welches zum Senden der Signale an dieses logische Device verwendet werden soll (Beispielsweise FHZ oder CUL). Hinweis: Beim Start weist FHEM jedem logischen Device das letzte physische Device zu, das Daten von diesem Typ empfangen kann. Das Attribut IODev muss nur gesetzt werden, wenn mehr als ein physisches Device fähig ist, Signale von diesem logischen Device zu empfangen.

Daraus lese ich im ersten Satz, dass das Setzen des physikalischen Device (in meinem Fall ein CUL) für das Senden von Signalen an das logische Device (mein FS20 SI3) wichtig ist. Aus dem letzten Satz hingegen lese ich, dass IODev nur gesetzt werden muss, um das physikalische Device für das Empfangen von Signalen vom logischen Device zu regeln - also so wie ich verstehe genau entgegengesetzt.

[rudolfkoenig]

Mit Senden ist "von FHEM senden" gemeint. Beim Empfang werden die Daten aller Geraete ausgewertet, IODev ist noetig, um nicht mit dem CUL im Keller das FS20 im Dach zu schalten. Mit mehr als einem CUL zu senden ist kontraproduktiv.

Eine merkbar bessere Vormulierung uebernehme ich gerne.

[duke-f]

So ist es schon klar, ich kam mit den "logischen" und "physikalischen" Devices durcheinander - liegt eindeutig an meinem mangelnden Verständnis. Eigentlich schon klar dass "von FHEM senden" und "von FHEM empfangen" gemeint ist, wenn nichts anderes erwähnt wird. Wird bestimmt auch irgendwo so gesagt.

Lediglich einen Deiner Sätze würde ich in die Commandref so 1:1 übernehmen, vor den Hinweis:

Beim Empfang werden die Daten aller Geraete ausgewertet

[justme1968]

das stimmt so aber auch nicht ganz.

wirklich ausgewertet wird nur die erste. alle folgenden über ein anderes iodev werden als doppelt erkannt und verworfen.

bis auf die rssi werte in den internals ist von den mehrfach empfangenen nachrichten nichts zu sehen.

das gilt zumindest für die meisten protokolle. hm ist glaube ich eine ausnahme.

[duke-f]

Ich habe eigentlich erst nie direkt nach den IODev für meine Geräte gesehen. Allerdings haben zwei bis drei der acht S300TH zeitweise derart Probleme gemacht, dass sie nicht von FHEM empfangen wurden. Einer davon war im gleichen Zimmer wie der per IODev zugeordnete CUL (genauer: Ein SCC), der andere ein Stock darüber. Dann abe ich bei beiden einen anderen CUL zugeordnet, der ein Stock tiefer liegt. Obwohl für den oberen nun sogar zwei Stahlbetondecken dazwischen liegen, wurden dann wieder regelmäßiger für alle die Werte registriert. Einige Wochen später habe ich das wieder geändert und prompt war der Empfang wieder schlechter.

Kann Zufall sein, aber irgendwie lies es mich daran zweifeln, dass FHEM das selbstständig optimal verwaltet.

[rudolfkoenig]

S300 (Modul CUL_WS) ist eine (doofe) Ausnahme: um die Anzahl der empfangbaren Geraete (der Adressraum laesst nur 8 zu) zu erhoehen, werden die mit IODev Attribut verehene Geraete trotz gleicher Adresse als unterschiedliche gewertet. Damit kann man einige S300 auf 433MHz umruesten oder oertlich trennen, und mit 2 CULs insg. 2x8 Sender empfangen.
Die Ausnahme ist deswegen doof, weil es zu etlichen Meldungen im Forum bzw. Verwirrungen gefuehrt hat.
Loesung: IODev Attribut fuer S300 nicht setzen.

[duke-f]

Dann wird mir einiges klar, jetzt kann ich einige der diesbezüglichen Beiträge auch plötzlich verstehen - und kann andererseits vielleicht meine im Keller liegenden Reserve-S300TH noch sinnvoll nutzen.

[TeeVau]

Und falls du die CUL_WS Devices löscht, musst du schnell ein save machen und einen shutdown restart. Ansonsten gibt es ein Verhalten, was eigentlich logisch ist, aber für den Anwender sehr verwirrend Hatte da mal etwas Zeit und Nerven investieren müssen