IT-Problem: Falscherkennung/Doppelschaltung

Begonnen von renemt, 28 Februar 2018, 21:52:20

Vorheriges Thema - Nächstes Thema

renemt

Hallo Intertechno-Auskenner,

ich habe aktuell ein Problem mit mehreren Intertechno PIR-1000 Bewegungsmeldern. Diese senden bekanntlich Protokoll V3. Ich habe sie in FHEM gemäß den vom CUL erkannten Codes definiert:

define bwm.A IT 01100010000000100011101110 0 1001
define bwm.B IT 01100010000000100101100010 0 1001
define bwm.C IT 01100010000001010001011010 0 1001

Das Problem: Ein-/Auschaltsignale von bwm.A werden auch als Signal von bwm.B erkannt und andersrum.
bwm.C lässt sich aktuell sogar gar nicht mehr anlegen (per autocreate z.B.) - weil sein Signal gleich als das von 3 anderen Meldern erkannt wird.

Meine FHEM-Version ist aktuell (fhem.pl:16228/2018-02-20).

Ich verwende einen CUL 433 (CC1101) mit a-culfw, der grundsätzlich mit all meinen vorhandenen Intertechno Schaltaktoren und Sendern problemlos funktioniert. Firmware: V 1.26.01 a-culfw Build: 271 (2017-09-18_20-23-44) CUL433 (F-Band: 433MHz), ccconf: freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB

Hat jemand von euch eine Idee, wie ich dem System beibringen kann, die Sender korrekt auseinander zu halten?

KölnSolar

guck Dir mal autocreateThreshold beim autocreate an. Das könnte Dir helfen.
Allerdings wundert mich Dein Problem schon etwas. Wie hast Du den Learn-Switch stehen ? Batterien voll ?
Bin mir nicht sicher, ob die evtl. auch mehrere Codes speichern können. Einfach noch einmal löschen und neu anlernen. Zur Sicherheit die Batterien beim Anlernen aus den beiden anderen herausnehmen.
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

renemt

Batterien: Voll.

Lern-Switch: Egal, der ist eigentlich nur dafür da, einmal Einschalt- (=SET) oder Ausschalt- (=DEL) Signale zu provozieren, die dann vom Empfänger zwecks Anlernen empfangen werden können. Im Betrieb hat das aber keine Auswirkung (habe bereits drei andere PIR-1000 seit zwei Jahren problemlos am Laufen).

autocreate ist hier auch irrelevant.

Mehrere Codes: Die Bewegungsmelder senden ja nur. Und zwar genau einen Code (den aber mehrmals) - den, den sie werksseitig implementiert bekommen haben.

Ich vermute das Problem eher bei der Erkennung oder Interpretation der Signale durch CUL und/oder FHEM:
- Kann es sein, dass die Codierung der Melder als das Schalten einer Gruppe interpretiert wird?
- Ist vielleicht die Erkennung durch den CUL nicht sauber und andere Parameter (Frequenz, Bandwith, ...) könnten Abhilfe schaffen?
- Gibt es evtl. einen Bug im IT-Modul oder der a-culfw?


Gruß,
René