Mein SelbstbauCul 433 reagiert auch auf HMS100TF (868MHz)

[nccfast]

Hallo,
ich habe einen HMS100TF. Dieser wird auch von einem CUL868 ausgewertet. Soweit alles gut.
jetzt habe ich mir vorgestern einen Selbstbau CUL433 zusammengebaut, um damit Revolt Steckdosen auszuwerten. Funktioniert auch.
Aber komischerweise reagiert mein CUL433 auch auf den HMS100TF. Der sendet doch mit 868 MHz. Wie kann das sein.

Auszug aus LOG mit verbose 5 für den CUL433:

Code Auswählen Erweitern


....
2015.08.15 16:27:29 5: CUL/RAW: /r53BDE100003200000000810F

2015.08.15 16:27:29 4: CUL_Parse: CUL433 r53BDE100003200000000810F -66.5
2015.08.15 16:27:29 5: CUL433 dispatch r53bde10000320000000081
2015.08.15 16:27:52 5: CUL/RAW: /H00000000000010

2015.08.15 16:27:52 4: CUL_Parse: CUL433 H00000000000010 -66
2015.08.15 16:27:52 5: CUL433 dispatch 810e04xx0510a0010000000000000000
2015.08.15 16:27:52 4: HMS device 0000 not defined, using the wildcard device 1000
2015.08.15 16:27:52 1: Error dewpoint: humidity invalid: 0
...


Was kann ich machen, dass der 433 nicht auf das Signal vom HMS100TF reagiert?

[Zrrronggg!]

Das ist in der Tat seltsam.

Was ich aber nicht ganz verstehe ist: Wieso stört dich das? Das HMS Device wirst du ja früher oder später definieren, oder? Und dann werden die Daten eben von 2 Funkschnittstellen empfangen.
Das macht ja nichts.

Wer mehrere 868 Schnittstellen hat (so wie z.b. ich) hat das "Problem" ja auch.

[nccfast]

Das Problem war, dass ich meine HMS100TF mit 0000 als TH_Wohnzimmer definiert hatte. Und da hat der CUL433 (warum weiss ich noch nicht), als Device TH_Wohnzimmer einfach reingeloggt. D.h. ich hatte immer 0-Werte  drin.
Habe jetzt das HMS100TF mit der Nummer com aotocreate definiert. Jetzt scheint er nicht mehr reinzuloggen.

Mich wundert aber immer noch, dass der CUL433 ein Signal vom HMS100TF empfängt.

[nccfast]

Ausserdem legt mir der autocreate immer folgendes an:

Code Auswählen Erweitern

define HMS100TF_0000 HMS 0000
attr HMS100TF_0000 IODev CUL433
attr HMS100TF_0000 room HMS
define FileLog_HMS100TF_0000 FileLog /mnt/2/Daten/fhem-5.6/log/HMS100TF_0000-%Y.log HMS100TF_0000:T:.*
attr FileLog_HMS100TF_0000 logtype temp4hum6:Temp/Hum,text
attr FileLog_HMS100TF_0000 room HMS
define SVG_HMS100TF_0000 SVG FileLog_HMS100TF_0000:temp4hum6:CURRENT
attr SVG_HMS100TF_0000 label "HMS100TF_0000 Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_HMS100TF_0000 room Plots


[Sebastian89]

Ich vermute mal auf dem Selbstbau-CUL sitzt der CC1101. Der kann sowohl 433Mhz als auch 868Mhz, die Platine ist allerdings immer nur für eine der beiden Frequenzen optimiert.

[Zrrronggg!]

Hm. Der kann beide Frequenzen - aber nicht ZUGLEICH. Das Teil wird per Befehl auf einen Frequenz konfiguriert. Das kann auch 567,89 sein. Dann empfängt er dann mit der eingestellten bwidth, die kann man ja auch frei konfigurieren.

Das er zugleich 886 und 433 empfängt geht meines Wissens nach an sich nicht.
Aber das Mysterium mag im Aufbau des Selbstbau CUL liegen. Wie der genau aufgebaut ist wissen wir ja nicht, oder?
Wenn der z.b. ZWEI CC1101 hätte ...

[SVLoneStar]

Hallo - das liegt m. E. n. am Empfang der Revolt-Dosen.
Das Protokoll der Revolts kann nicht vollständig dekodiert werden. Wenn ich mich richtig erinnere, ging es um eine zweite Checksum, die nicht interpretiert werden konnte und daher nicht zum Check der 'Unversehrtheit' der Pakete herangezogen werden kann. Hierdurch werden bei Revolt hin und wieder (oder sehr oft) 'verhunzte' Pakete empfangen. Sprich - Dein nanoCUL433 empfängt nicht 868MHz, sondern legt nur fälschlicherweise ein Gerät an, das mit 868MHz arbeitet.
Auch bei mir wurde jedesmal, wenn ein 433er nanoCUL Revolts empfangen sollte, auf der entsprechenden FHEM-Instanz ein solcher HMS100TF_0000 angelegt. Den setzte ich dann auf 'ignore' und gut. Ist natürlich blöd, wenn Du tatsächlich einen solchen im Einsatz hast und falsche Einträge ins richtige Log-File kommen...ID ändern?
Ebenso erhalte ich beim Betrieb von Revolts an einem nanoCUL433 sehr häufig die Fehlermeldung 'Unknown code EFFFFFFFFFFFFFFFFFF' im Log (siehe dazu hier: http://forum.fhem.de/index.php/topic,41383.msg345893.html#msg345893).

Beides tritt mit der neuesten Version der a-culfw (1.10.01) bei mir nicht auf - allerdings werden damit im Moment jede Menge 'falscher' Revolts per autocreate angelegt...wie gesagt, viele verhunzte Pakete...aber das kriegt man mit autocreateThreshold in den Griff

[Tedious]

Ich hab ein ähnliches Problem - bei mir empfängt - warum auch immer - der Cul868 433MHz Signale und legt Geräte an. Ich biege das denn immer in der Config auf den 433 um und gut ist es. Warum das so ist - keine Ahnung?!

[SVLoneStar]

Evtl. weil der 868er als 'letzter' in der Config steht und daher per default bei neuen Devices als IODev eingetragen wird...?


Sent from my iPhone using Tapatalk

[Tedious]

Hmmm... die Reihenfolge ist 433, 868, Jeelink.

[SVLoneStar]

Hmmm...war nur eine Idee...dreh' die defines der CULs doch mal rum und schau', was passiert...?


Sent from my iPhone using Tapatalk

[Zrrronggg!]

Die Reihenfolge hat nur Einfluss auf das Senden, nicht den Empfang. Prinzipiell empfangen alle Geräte die das können und reichen an FHEM weiter, FHEM sortiert das dann aus. Vergleiche dazu attr global dupTimeout, das nämlich den minimalen Abstand eines mehrfachen empfangen Kommandos festlegt, nach dem FHEM es als NICHT das selbe Kommando auffasst.

Es wird hier schlicht so sein, dass der Cul868 auch 433 physikalisch empfängt.

Wie ich schon mal schrieb:
"Aber das Mysterium mag im Aufbau des Selbstbau CUL liegen."