Empfangsprobleme S300TH

[duke-f]

Obwohl es diese Sensoren wohl nicht mehr zu kaufen gibt, will ich das Thema nochmal etwas in den Vordergrund holen. Habe in vielen früheren Themen schon unterschiedliche Berichte gelesen aber damit keine Verbesserung erzielen können.

Derzeit betreibe ich 8 S300TH und 3 CUL/SCC/CUNX für 868 MHz sowie drei CUL/CUNX für 433 MHz. Vielleicht für das folgende von Bedeutung: In der Config ist einer der CUL 433 als letzter definiert. Gebe ich nun für die S300TH keine IODev an, wie es an anderer Stelle schon mal empfohlen wird, wird automatisch dieser CUL als IODev angegeben und es werden gar keine Werte der S300TH empfangen. Gebe ich einen der CUL 868 selber an - egal welcher, werden die S300TH über kurz oder lang erkannt.

Aber egal, wie ich die Parameter der CUL auch definiere, sens = 4, 8 oder 12, Frequenz 868,3 oder 868,35 MHz und gleiches für die Bandbreite, werden einzelne S300TH immer nur sehr selten empfangen. Mal über die ersten Monate des Jahres verglichen, ist der schlechteste durchschnittlich nur halb so oft registriert wie der beste. Dabei bringen auch Änderungen der Position keine Verbesserung, Sendestärken sind durchaus ausreichend.

Ein anderes Gerät aus früheren Zeiten hingegen (für Kenner: Ein XS1) registriert alle 8 S300TH hingegen mit wesentlich höherer und stabilerer Häufigkeit.

[stromer-12]

Ich habe hier 7 S300TH welche mit folgender Config empfangen werden:

Code Auswählen Erweitern

freq:868.315MHz bWidth:406KHz rAmpl:42dB sens:8dB

Vielleicht hilft es auch mal den Standort der S300TH leicht zu verändern, mitunter reichen wenige Zentimeter.

[duke-f]

Sind die so wirklich über lange Zeit stabil? So fein habe ich die Einstellungen zugegeben noch nicht variiert. Da habe ich also noch Potential für Verbesserungsversuche.

Besten Dank für die Antwort

[rudolfkoenig]

Die IODev Behandlung der S300TH (bzw. CUL_WS) ist speziell: Wenn ein IODev angegeben wird, dann muessen die Daten von diesem IODev stammen, ohne IODev duerfen sie von irgendeinem der Empfaenger kommen. Ich empfehle die Variante ohne IODev, da man eine IODev-Trennung nur mit groesster Sorgfalt (z.Bsp. Frequenzumbau _UND_ raeumliche Trennung) hinkriegt.

Ich empfange meine S300TH's seit Jahren mit dem default "freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB", sie wurden bei dieser Default-Erstellung beruecksichtigt, siehe http://culfw.de/FREQTEST. Da ich nicht von einer exakter Fertigung bei den Geraeten ausgehe, sind fuer andere Geraete evtl. andere Parameter sinnvoll.

[rr725]

hallo,
ich habe sieben stück davon im einsatz und mit
freq:868.315MHz bWidth:406KHz rAmpl:42dB sens:8dB
egal in welcher ecke im haus sie versteckt sind, keinerlei empfangsprobleme.
alle sensoren senden ca alle drei minuten.

nur einer hatte letzte woche nichts mehr gesendet, da batterien leer. batterien getauscht und seit dem nur noch probleme mit dem teil. ein, zwei, drei meldungen pro stunde. und da denkt man schon, was soll das. wieso, weshalb, warum.  batterien über nacht raus, getestet, noch immer probleme.hm.....
da ich noch eine adresse zur verfügung hatte, habe ich die adresse geändert und was soll ich sagen...seit dem sendet auch er wieder alle drei minuten. erklären kann ich mir das nicht.aber egal, hauptsache es funzt wieder

[duke-f]

Ich empfehle die Variante ohne IODev

Das hatte ich ja versucht. Gebe ich aber kein IODev an, wird in den Internals automatisch einer der beiden CUL 433 angegeben, nämlich der letzte definierte, und es kommen gar keine Werte an.

[stromer-12]

Was passiert wenn du die Definition des CUL433 vor die anderen legst?

stromer on tour

[duke-f]

Das muss ich dann nochmal probieren. Hatte das zwar schon, aber ist einige Zeit her. Im Moment habe ich allen den gleichen CUL 868 zugewiesen, außer dem einen am weitesten entfernten. Der hat den SCC. Es scheint gerade stabil zu laufen. Aber wie ich schon von anderen gelesen habe, rechne ich damit, dass es irgendwann wieder hakt.

[rudolfkoenig]

Das hatte ich ja versucht. Gebe ich aber kein IODev an, wird in den Internals automatisch einer der beiden CUL 433 angegeben, nämlich der letzte definierte,

Sorry, ich war nicht genau, und die Sache ist etwas chaotisch. Das Internal IODev wird gesetzt, ist aber beim Empfang generell irrelevant. Massgaeblich ist in diesem Fall das Attribut IODev, was im CUL_WS Modul speziell behandelt wird, und _zusaetzlich_ auch das Internal IODev setzt.
Ohne IODev Attribut werden im CUL_WS Modul alle Signale dem zuletzt definierten CUL_WS mit dem entsprechenden Code(1-8) zugeordnet. Mit IODev Attribut wird zur Unterscheidung zusaetzlich das meldende Geraet (als IODev bekannt) hinzugezogen.

Damit ist auch die Definitionsreihenfolge der CUL fuer den S300TH Empfang irrelevant.

und es kommen gar keine Werte an.

Das glaube ich erstmal nicht, und brauche einen Beweis dafuer.

[duke-f]

Da kann ich Deine Zweifel verstehen. Aber wie soll ich das beweisen? Dann musst Du schon mal vorbei kommen

[duke-f]

Etwas ab vom Thema:
Das mit der IODev für den Empfang gilt dann auch für die FHTs? Also auch die FHTs regeln selber, über welchen CUL sie empfangen warden? Und nur das senden geht über den per Attribut angegebenen?

[rudolfkoenig]

Das Prinzip gilt fuer alle Geraete in FHEM.

[duke-f]

War ja eigentlich auch idiotisch von mir, dass ich einzelne CULs entlasten wollte durch den Empfang definierter IODev.  Wer empfängt, ist ja egal.