ITT-1500 Handsender Code (selbstlernend) für ITR-1500 auslesen

[PatrickStar]

Moin,

Aufgabenstellung:
Selbstlernende Funksteckdose ITR-1500 soll neben FHEM zusätzlich mittels Handsender (ITT-1500) betrieben werden. Dazu muss der Code des Handseders ausgelesen werden, damit dieser bei der Definition in FHEM verwendet werden kann (Anlernen der Steckdose in FHEM mit eigenem Code funktioniert einwandfrei).

Setup:
Raspberry Pi 4B 4GB RAM
Nano CUL868

Versuch 1:
Entsprechend dieser Anleitung versucht, mittels CUL auszulesen:

Code: [Auswählen]

git clone https://github.com/npat-efault/picocom
cd picocom
make

./picocom -b 38400 /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -c
X21
Wenn ich eine Dose über FHEM mittels CUL schalte, wird hier etwas ausgelsesen (eigentlich nur kauderwelsch). Wenn ich die ITT-1500 bediene liest er nix.

Ich muss dazu sagen: Ich habe die Firmware vom Hersteller drauf. An das Flashen mit a-culfw habe ich mich nicht getraut. Kein Plan, wie ich das rückgängig mache...

Versuch 2 (u. A. hier):
wiringPi auf Version 2.52 updated
Transmitter Module HFY-FST und Receiver Module HFY-J18 Rev.2.0 mit Jumperkabeln direkt wie folgt angeschlossen:

Transmitter

• PIN1, ATAD = Pi PIN 11 = wPi GPIO 0 = Pi GPIO 17
• PIN2, VCC = Pi PIN 4
• PIN3, GND= Pi PIN 9

Receiver

• PIN1, ANT = vorgelötete Mini-Antenne
• PIN2, VCC = Pi PIN 2
• PIN3, DATA = Pi PIN 13 = wPi GPIO 2 = Pi GPIO 27
• PIN5, GND = Pi PIN 6

Code: [Auswählen]

git clone https://github.com/ninjablocks/433Utils.git --recursive
cd 433Utils/RPi_utils
make all
sudo ./RFSniffer
Wenn ich im neuen Terminal-Fenster mit

Code: [Auswählen]

cd 433Utils/RPi_utils
sudo ./codesend 1234einen Code sende, empfange ich den 3 mal hintereinander.

Beim Betätigen des ITT-1500 wird wieder nichts empfangen.

Was mich auch nicht ganz versändlich ist: Dezimalcodes bis 8 stellen werden verschickt und 1:1 in 3facher Ausführung empfachen. Längere Codes werden irgendwie umgerechnet. Wenn ich den in FHEM definierten Code FF0000000F FF (ein) und F0 (aus) in Dezimalzahlen umrechne, kommt da 280375465086975 bzw. 280375465086960 raus. Sende ich den Einschaltcode dezimal bekomme ich vom Receiver sowas in der Art heraus:

Code: [Auswählen]

Received 16777215
Received 16777215
Received 16777215

Hat jemand eine Idee woran das liegen kann, bzw. wie ich meine Aufgabenstellung gelöst bekomme?

[Beta-User]

Vorab mal willkommen im FHEM-Forum !

Zu Wiring-Pi kann ich wenig sagen, Pi-GPIO sollte man mAn. nur dazu nutzen, dem Pi eine RTC zu verpassen und ggf. ein Homematic-Modul draufzustecken... Aber grade der Pi 4 ist bekannt dafür, dass er RF-Störfeuer - insbesondere im Nahbereich - verursacht. Könnte also daran liegen, dass der "Superhet" so "kurzssichtig" ist.

Ein 868-er CUL ist nicht für 433MHz optimiert, falls du ihn also dafür beschafft hast, tausche ihn gegen einen 433-er und lasse dir gleich die aktuelle (Entwickler-) Signalduino-Firmware draufspielen. Die ist nämlich im Moment die universellste Lösung in FHEM für den Empfang auf 433MHz, gefolgt von a-culfw (die ist etwas einfacher in der Handhabung in FHEM; der Verkäufer bietet beide/alle drei Alternativen an!).

Alternativ: Beschaffe einen Arduino Nano und löte da den 433-MHz-Kram dran (ebenfalls Signalduino, aber "klassisch" ohne CC1101).

[frank]

An das Flashen mit a-culfw habe ich mich nicht getraut.

mein cul mit a-culfw plus autocreate hat schon vor jahren beim druck auf ein knöpfchen der fb jeweils ein device angelegt.

[Beta-User]

mein cul mit a-culfw plus autocreate hat schon vor jahren beim druck auf ein knöpfchen der fb jeweils ein device angelegt.

War/ist das auch ein 868er... ?

[frank]

War/ist das auch ein 868er... ?

nee, das war und ist natürlich ein 433'er. 

[Beta-User]

  Ich habe beide Varianten, (u.A. ein) 433-Modul an MapleCUN (=>a-culfw) und einen Signalduino (erst mit Superhet, jetzt auf 433-er CC1101 mit irgendeiner Developer-Zwischenversion aus vor Jahren). Nur letzterer kann meine Dunstabzugshaube schalten bzw. den Handsender direkt dekodieren... (und ich gehe davon aus, dass es keine Regression beim Dekodieren der Signale dieses speziellen Geräts zwischenzeitlich gab, im Gegenteil: die hat sich auch seitdem weiter verbessert, ich brauch's nur nicht aktueller.)

(Für "klassische" und "gute" Hardware sollte es ziemlich egal sein, was man nimmt, nur in speziellen Situationen dürfte mal die eine, mal die andere Variante (oder auch Signalduino-Derivate!) zielführend sein.)

[PatrickStar]

mein cul mit a-culfw plus autocreate hat schon vor jahren beim druck auf ein knöpfchen der fb jeweils ein device angelegt.

Mein CUL hat jetzt a-culfw:

Code: [Auswählen]

Internals:
   CFGFN     
   CMDS       ABCEeFfGiKlMNRTtUVWXxZ
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0@38400 0000
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0@38400
   FD         7
   FHTID      0000
   FUUID      60aacdc3-f33f-3c66-14a2-5c620017147b67d2
   NAME       CUL868
   NR         21
   PARTIAL   
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) nanoCUL868 (F-Band: 868MHz)
   initString X21
   MatchList:
     0:FS20V    ^81..(04|0c)..0101a001......00[89a-f]...
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2021-05-23 23:48:54   cmds             A B C E e F f G i K l M N R T t U V W X x Z
     2021-05-24 00:23:28   raw             isFF0000000FF0
     2021-05-23 23:48:54   state           Initialized
Attributes:
   rfmode     SlowRF
autocreate müsste ja standardmäßig aktiv sein. Wenn ich jetzt einen Schalter betätige oder eine Steckdose mittels Handsender anlerne passiert nichts. Fehlt da etwas im Setup?

Code: [Auswählen]

Internals:
   FUUID      60aacb94-f33f-3c66-f401-af2ab421e6a7501c
   NAME       autocreate
   NOTIFYDEV  global
   NR         8
   NTFY_ORDER 50-autocreate
   STATE      active
   TYPE       autocreate
Attributes:
   filelog    ./log/%NAME-%Y.log
Die Anleitung 1 im Originalpost geht mit a-culfw leider auch nicht 

[Beta-User]

868MHz => warum sollte der gut 433-er Signale empfangen?

[frank]

wenn du infos postest, dann bitte "list <deviceName>".

mit "initString: X21 Ar" hast du sicherlich homemaic mode eingestellt. so wird das nie was.

[PatrickStar]

868MHz => warum sollte der gut 433-er Signale empfangen?

Hier steht, dass das Ding auch 433Mhz senden kann. Den 433Mhz ITR-1500 kann ich damit auch schalten. Oder ist das hier wörtlich zu nehmen und er kann auf der Frequenz nur senden aber nicht empfangen?

wenn du infos postest, dann bitte "list <deviceName>".

Sorry, bin ganz neu hier. Habe ich im Post oben angepasst.

mit "initString: X21 Ar" hast du sicherlich homemaic mode eingestellt. so wird das nie was.

Er sagte, dass man das auf HomeMatic stellen soll. Senden geht damit auch. Ebenso mit SlowRF. Welcher Modus wäre denn der richtige für mein Problem?


Hat noch jemand eine Idee, warum Empfangen mittels 433Mhz Receiver über GPIO am Pi nicht funktioniert hat (im ersten Post Versuch 2)?

[Beta-User]

Hier steht, dass das Ding auch 433Mhz senden kann. Den 433Mhz ITR-1500 kann ich damit auch schalten. Oder ist das hier wörtlich zu nehmen und er kann auf der Frequenz nur senden aber nicht empfangen?

_Vielleicht_ kann ein auf 868MHz optimierter Schwingkreis auch 433MHz-Signale empfangen.

ABER:
a) muss er dafür entsprechend INITIALISIERT werden, und
b) ist es physikalischer "abuse". Klappt vielleicht mit relativ starken Signalen, vermutlich aber eher nicht.
Es macht wenig Sinn, hier einen Crash-Kurs Antennentechnik hinzuschreiben, Kurzfassung (weiterhin): Lass das und beschaffe passende Hardware!

Er sagte, dass man das auf HomeMatic stellen soll.

Nur weil irgendjemand in einem Video 2016 irgendwas hat verlauten lassen, ist es noch lange nicht richtig.
Diese Einstellung war "richtig", weil er den CUL für Homematic nutzen wollte.

Schon damals nicht richtig war, dass ein CUL ein optimales Interface für Homematic gewesen wäre.
Jedenfalls ist im Wiki (gefühlt: schon immer) zu lesen, dass ein Parallelbetrieb von Homematic und anderen Modi des CUL nicht geht, und 433MHz-Intertechno-Protokoll ist halt (ganz unabhängig von der Frequenz) SlowRF, und es steht auch schon länger drin, dass man für Homematic besser eine für HM optimierte firmware-Variante (samt weiterer FHEM-Module) nehmen sollte...
Jedenfalls: Der HM-Mode stellt "hart" eine ganz bestimmte Empfangsfrequenz (aus dem 868-er Bereich) ein => Ende Gelände mit 433-er Empfang!

Senden geht damit auch. Ebenso mit SlowRF. Welcher Modus wäre denn der richtige für mein Problem?

Zum Senden wird kurzzeitig umgeschaltet, was weder antennentechnisch optimal ist, noch gut für den CC1101 (EEPROM-wear-out). Aber wenn du das mit der Antennentechnik immer noch nicht glauben magst, dann versuch's mit SlowRF und passe dann die cc-Settings entsprechend an...

[KölnSolar]

Beta hat es eigentlich alles richtig verdeutlicht.

Hier steht, dass das Ding auch 433Mhz senden kann. Den 433Mhz ITR-1500 kann ich damit auch schalten. Oder ist das hier wörtlich zu nehmen und er kann auf der Frequenz nur senden aber nicht empfangen?

Um es klarer zu sagen: der 868Mhz ist eine Krücke. Kann f. DEINE Belange funktionieren oder auch nicht.
Nur, was sind DEINE Belange ? 
Was geht: einmalig so einstellen, dass

Dazu muss der Code des Handseders ausgelesen werden,

Was nicht geht: dauerhaft(gleichzeitig) 433 u. 868 EMPFANGEN
Was vielleicht geht: dauerhaft 433 EMPFANGEN(u. senden). Reichweitenproblematik hat Beta ja erklärt.

Grüße Markus

[frank]

der cul433/slowRF für meine IT devices zeigt folgende standard einstellungen:

Code: [Auswählen]

cul433 ccconf => freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB

[fhemjan]

Mal ein amateurhafter Beitrag dazu:

Ich habe auch das System mit ITR-1500 und ITT-1500. Mit nanoCUL433 funktioniert das Erstellen der Steckdosen sehr einfach mittels

Code: [Auswählen]

define <Steckdosenname> IT 000000000F FF F0über den on-Befehl aus FHEM kann ich diese dann anlernen.

Die Fernbedienung ist jedoch etwas tricky. Zunächst erkannte er alle Tasten über den Eventmonitor als Geräte und hat sie automatisch im Raum IT abgelegt. Nur das dann plötzlich jeder Schalter alle Steckdosen geschaltet hat. Ich würde gern den Schalter nur für die Bedienung in FHEM nutzen und die Steckdosen auch nur durch FHEM schalten lassen.
Ich war verwirrt und habe mittels ALL OFF alle Codes gelöscht und in FHEM die Devices der Taster 2 und 3 gelöscht, weil ich dachte da geht schon nix kaputt.. Nun ist es so, das mir die Tasten 2 und 3 des Schalters im Eventmonitor UNKNOWNCODE ausgeben:

Code: [Auswählen]

2022-08-06 12:16:04.638 CUL nanoCUL UNKNOWNCODE i5a5995956a669656
2022-08-06 12:16:21.262 CUL nanoCUL UNKNOWNCODE i5a5995956a669659
Beim ersten Schalter ist hingegen alles gut, da ich ihn rechtzeitig umbenannt und nicht in meinem Wahn gelöscht hatte. Eventmonitor zeigt beim an/aus schalten:

Code: [Auswählen]

2022-08-06 12:16:23.342 IT Schalter1 on
2022-08-06 12:16:24.447 IT Schalter1 off
Könnt ihr sagen wie ich mit den Tastern 2 und 3 nun auch ein Device für einen Schalter erstelle? Sie werden ja erkannt, aber ich bekomm sie nicht in meinen IT Raum..

[fhemjan]

Ok.. ich konnte mir selbst helfen. Ein Neustart hat es geschafft.