Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.41

[Bastel-Frank]

Nicht sehr lange ... sie sind im Produktiven Einsatz ... und der WAF ist in Gefahr

aber keinen Stress, ich habe eine fhem-Umgebung mit Standard-FW aufgesetzt. Es wäre aber zukünftig schön, wenn man solche Fälle auch mit deiner FW lösen könnte.

[noansi]

Hallo Frank,

Es wäre aber zukünftig schön, wenn man solche Fälle auch mit deiner FW lösen könnte.

Die Zukunft ist jetzt.
Im Anhang der Quellcode zur adaptierten Version des hmcfgusb Pakets 1.03-git von Michael Gernoth.
Es wird dafür die tsculfw VTS 0.28 oder höher benötigt.

Erfolgreich getestet habe ich ein OTA-Firmwareupdate mit CULs mit tsculfw VTS 0.29 tsculfw VTS 0.38.

@Michael: flash-ota.c, culfw.c und culfw.h sind geändert (und version.h, sowie LICENSE), wäre schön, wenn Du es einarbeiten könntest.

Gruß, Ansgar.

EDIT: noch ein Update, da bei Flashen mit Seriennummer die HMID des devices nicht im CUL registriert wurde.
EDIT2: und noch ein kleines Update, damit bei mangelnden credits die ungefähre Wartezeit bis zur Vollaufladung angezeigt wird.
EDIT3: Update für VTS 0.34 und höher
EDIT4: Update für gestackte CULs

[Bastel-Frank]

Hallo Ansgar,

vielen lieben Dank ... mal wieder ... bei Dir. Was für ein Top-Service!

Wenn ich könnte, würde ich Dir ein paar Bierchen rüberschieben. Das welcher Region DE kommst Du?

LG
Frank

[noansi]

Hallo Frank,

der Quellcode oben ist aktualisiert, weil mir noch was im Bezug auf OTA-Firmwareupdate mit Seriennummer aufgefallen ist.

Gruß, Ansgar.

[noansi]

Hallo Frank,

zum Thema Bier ist habe ich noch eine kleine Ergänzung eingebaut, die die ungefähre Wartezeit bis zur Vollaufladung der credits angibt. Damit kann man die Zeit sinnvoller nutzen.
Allerdings sollte man sich beim Warten eine gewisse Restzuzurechnungsfähigkeit erhalten, da die für korrekte Befehlseingabe und device-Bedienung erforderlich ist. 

Gruß, Ansgar.

[frank]

ota fwupdate sollte trotzdem normal über cul_hm funktionieren. einfach eine optionale waittime angeben.

fwUpdate [onlyEnterBootLoader] <filename> [<waitTime>]
update Fw of the device. User must provide the appropriate file. waitTime can be given optionally. In case the device needs to be set to FW update mode manually this is the time the system will wait.
"onlyEnterBootLoader" tells the device to enter the boot loader so it can be flashed using the eq3 firmware update tool. Mainly useful for flush-mounted devices in FHEM environments solely using HM-LAN adapters.

nach dem senden des befehls muss innerhalb der waittime, das device manuell gebootet werden. das sollte im changelog der fw datei beschrieben sein.

[jw1hal]

Hallo,

ich bin noch relativ neu und fuchse mich so nach und nach in dieses sehr komplexe Thema. So habe ich noch große Probleme mich richtig exakt auszudrücken oder eben gleich die wichtigen Informationen zu liefern, weil ich nicht immer genau weiß, wie man da genau ran kommt. Das kommt eben mit der Zeit, jeder hat mal angefangen.

Ich fange mal an zu berichten. Nachdem meine 8 Fenstersensoren mit der vorherigen CUL-Firmware sich nicht pairen ließen, bin ich auf TSCUL aufmerksam geworden und habe zunächst erst einmal den 868iger Nano-CUL über Fhem geflasht. Das ging auch nicht sofort, erst Taste drücken, gedrückt halten und CUL einstecken hat es gebracht.
Ein Fenstersensor ließ sich auch nicht richtig pairen und peeren, so dass ich ihn zwar im Peer vom Thermostat sah, aber nicht andersherum. Auch die Meldungen "R-05_BW_Heizung_WindowRec-expectAES off" und "R-05_BW_Heizung_WindowRec-peerNeedsBurst on" blieben auf "set" stehen. Das habe ich 2 Tage probiert und es hat alles nix geholfen. Einen nachbestellt, mit dem ging es sofort. Der eventuell Defekte geht eben zurück.

Ich habe noch einen Fernseher über eine Funksteckdose (433 Mhz) laufen, die ich nicht in Fhem integriert bekomme. Als ich früh nach Hause kam, wollte ich diese Funksteckdose schalten und sie zuckte  auch am darauf folgenden Tag gar nicht. Erst Neustart vom PI oder Entfernung der  CUL´s lies diese Steckdose wieder schalten, so dass ich vermutete, der CUL sendet dauerhaft und stört den Funkverkehr. Da ich nur den 868iger geflasht hatte, dachte ich mir, dass es sich nicht verträgt, wenn der 433iger über die alte Firmware und der 868iger über die TS-Firmware läuft. Also flashte ich den 433iger auch. Mit dem lief auch erst einmal alles, muss ich aber noch beobachten, weil ich die letzten Tage mehrere Dinge getan habe.
So habe ich mich heute auch mit dem "99-usb-serial.rules-Thema" beschäftigt und bin letztendlich leider daran gescheitert. Bei den CUL´s stand zwar "Initialized", aber s in der VCCU stand "CUL_868:disconnected" und beide CUL´s funktionierten nicht. Also habe ich bei CUL´s wieder direkt mit dem USB-Port zugewiesen und nun funktionieren sie wieder.

Inhalt der Datei in: \etc\udev\rules.d\

Code Auswählen Erweitern

SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A9G7BTLL", SYMLINK+="CUL868"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="433", SYMLINK+="CUL433"

Das ergab dmesg:

Code Auswählen Erweitern

[    2.630149] usb 1-1.2: New USB device found, idVendor=0403, idProduct=6001
[    2.630158] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    2.630165] usb 1-1.2: Product: FT232R USB UART
[    2.630171] usb 1-1.2: Manufacturer: FTDI
[    2.630177] usb 1-1.2: SerialNumber: A9G7BTLL

[    3.184894] usb 1-1.3: New USB device found, idVendor=0403, idProduct=6001
[    3.184910] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    3.184919] usb 1-1.3: Product: NANO CUL
[    3.184927] usb 1-1.3: Manufacturer: SHK
[    3.184934] usb 1-1.3: SerialNumber: 433

Damit hatte ich es eingebunden:

Code Auswählen Erweitern

/dev/CUL433@12000000 0000
/dev/CUL868@12000000 4321

Und damit war es vorher und ist es auch jetzt wieder eingebunden:

Code Auswählen Erweitern

/dev/serial/by-id/usb-SHK_NANO_CUL_433-if00-port0@38400 4321
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9G7BTLL-if00-port0@38400 4321


Mein eigentliche Frage ist die folgende Meldung, über die ich im Netz auch nix weiter finde:

Code Auswählen Erweitern

2018.11.16 19:12:33 2: TSCUL_Parse: CUL_433 unknown message CC0 = 0D / 13
Diese taucht immer wieder im Log auf.

Dann hatte ich auch mal diese Meldung gesehen:

Code Auswählen Erweitern

2018.11.15 04:00:13 3: CUL_433: Unknown code NOCCA, help me!
Diese soll wohl besagen, so hatte ich es gelesen, dass die Frequenz belegt war und er deswegen nicht sendete. Dieses konnte ich die letzten Stunden nicht mehr sehen. Mal schauen, ob es morgen früh wieder da ist und mit dem weiter oben beschriebenen Problem zusammenhängen könnte.

Dann verstehe ich auch ein paar Meldungen nicht, die mich etwas verwirren und denken lassen, dass die beiden CUL´s auf den jeweils anderen Frequenzen senden.
So steht bei dem 433iger CUL:

Code Auswählen Erweitern

Internals:
   VERSION    VTS 0.29 CSM868
   READINGS:
     2018-11-15 06:21:40   ITSndFreq       433.920MHz +0.000kHz
     2018-11-15 06:25:17   ccconf          freq:868.300MHz freqOffs:0.000kHz bWidth:325kHz freqIF:177.73kHz rAmpl:42dB sens:12dB dRate:2.461kBit/s
     2018-11-15 06:22:18   version         VTS 0.29 CSM868

Und bei dem 868iger CUL steht:

Code Auswählen Erweitern

Internals:
   VERSION    VTS 0.29 CSM868
   READINGS:
     2018-11-15 04:21:55   ITSndFreq       433.920MHz +0.000kHz
     2018-11-15 06:23:33   ccconf          freq:868.300MHz freqOffs:-20.630kHz bWidth:101kHz freqIF:152.34kHz rAmpl:33dB sens:8dB dRate:9.993kBit/s
     2018-11-16 18:45:56   version         VTS 0.29 CSM868

Wieso steht bei dem 868iger etwas von 433 und bei den 433iger etwas von 868?


Das sind Fragen über Fragen und ganz sicher nicht ganz so fachmännisch, wie ihr es gern erwartet. Aber es ist ja noch kein Meister vom Himmel gefallen. Und selbst das Lesen, Lesen und nochmals Lesen von diversen Wiki´s und dieser Commandref ist auch sehr mühsam und unverständlich, wenn einem einfach die Erfahrung und das dafür nötige Grundwissen fehlt, was man sich nach und nach aneignen muss. Nur wenn ich nun trotz stundenlangen Suchen, Lesen und Probieren doch nicht weiter komme, muss ich irgendwo fragen, was mir unklar ist und wofür ich nirgends eine Erklärung finde, auch wenn es für manch einen von euch vielleicht ziemlich lächerlich ist.


Gruß jw1hal

[RaspiLED]

Hi,

Edit: Ich lerne jeden Tag dazu und TSCUL kann also auch 433

Rest daher ignorieren und weiter unten lesen! Danke für die Nachhilfe!

[ignorieren]
Offtopic hier ist Dein 433 nanoCUL. Flashe dort bitte die a-culfw und dann ist der fine und wird voraussichtlich auch Deinen Fernseher anschalten können. Falls nicht mach einen eigenen Thread unter Anfängerfragen auf. Da helfen Wir weiter für 433!

Dein 868 mit TS CUL sieht doch gut aus! Die 433.920 MHz würden verwendet, falls Du darüber Intertechno (z.B. Deinen Fernseher) schalten würdest. Aber eben nur ganz kurz und dann wieder zurück zu 868.300 MHz.

[/ignorieren]

Kurzum alles okay bei 868!

Gruß Arnd


Gesendet von iPhone mit Tapatalk

[noansi]

Hallo jw1hal,

große Probleme mich richtig exakt auszudrücken oder eben gleich die wichtigen Informationen zu liefern

Das erste wäre, in der zeitlichen Reihenfolge zu berichten, damit Ursache und Wirkung auch in Zusammenhang zu bringen sind.
Dann ist ein list von den fraglichen Komponenten auch immer hilfreich.

Funksteckdose (433 Mhz) laufen, die ich nicht in Fhem integriert bekomme.

Welches Protokoll verwendet die Funksteckdose? IT?

der CUL sendet dauerhaft und stört den Funkverkehr

So habe ich mich heute auch mit dem "99-usb-serial.rules-Thema" beschäftigt

Das war der richtige Ansatz, um eine feste Schnittstellenzuordnung auch im Falle von Disconnect/Reconnect zu erhalten, woran es zuvor wohl gekrankt hat. Deine 99-usb-serial.rules sieht gut aus.

/dev/CUL433@12000000 0000
/dev/CUL868@12000000 4321

ist falsch, da Du nanoCULs zu verwenden scheinst.

Code Auswählen Erweitern

/dev/CUL433@38400 0000
/dev/CUL868@38400 4321
Die 38400 ist für nanoCULs richtig, damit der USB-Seriel Interface Chip auf der nanoCUL Platine mit der richtigen Baudrate eingestellt wird.

Die 4 Ziffern danach sind die FHT ID. FHT setzt Du aber nach Deinem Bericht nicht ein. Wenn Du bei dem 868MHz CUL nicht das Attribut "hmId" setzt, dann wird mit den 4 Ziffern 4321 die hmId F14321 ersatzweise festgelegt.

2018.11.16 19:12:33 2: TSCUL_Parse: CUL_433 unknown message CC0 = 0D / 13

Beim nanoCUL ist der Speicherplatz knapp, daher ist das Feature des InterruptCounters für SlowRf nicht in die Frimware reincompiliert, weshalb der nano auf die CC0 Anfrage mit CC0 = 0D / 13 antwortet und nicht mit einer Ci Antwort, wie es das 00_TSCUL.pm Modul erwartet. Das muss ich wohl mal ausfiltern, danke für den Hinweis. Ist aber erst mal nicht tragisch, außer dass es Dein Log füllt.

Wieso steht bei dem 868iger etwas von 433 und bei den 433iger etwas von 868?

ITSndFreq ist die Sendefrequenz für IT Befehle. Wenn Deine Dose also auf 433.92MHz auf IT Schaltbefehle lauscht, ist das richtig so.
Andere SlowRF Befehle werden von dem 433er auf 868.3MHz gesendet und generell auf 868.3MHz in der gewählte Einstellung empfangen. Die Frequenz solltest Du beim 433er auf 433.92MHz umstellen. Das geht mit set freq 433.92 in fhem.
Wenn Du den Anschluss A0 (entsprechend PortC Bit0 am Prozessor) am nanoCUL mit 150Ohm nach GND verbindest, dann sollte sich der nanoCUL mit tsculfw in der Version auch als CSM433 melden und die Frequenz auch auf 433.92Mhz als Firmwaredefault (Rücksetzen mit e) einstellen. Alternativ kann man das mit Anpasung der board.h auch fest in die Firmware reincompilieren, statt A0 mit 150Ohm nach GND zu verbinden.

Den 868er betreibst Du mittels des Attributs rfmode auf HomeMatic. Damit wird der nanoCUL auf 868MHz Sende- und Empfangsfrequenz im passenden Modus eingestellt. Gleichwohl könnte er IT Befehle auf 433.92Mhz senden, aber mit sehr schlechter Reichweite, weil die Anpassung der Elektronik nicht passt.

Mittels IODev bestimmst Du beim Schaltmodul (IT?) für Deine 433MHz Dose, welcher nanoCUL tatsächlich für das Senden verwendet wird.

Gruß, Ansgar.

[noansi]

Hallo Arnd,

Offtopic hier ist Dein 433 nanoCUL.

Nicht ganz.
Die a-cuffw bietet sicherlich mehr Protkollunterstützung für unterschiedliche SlowRF Protokolle.

Die tsculfw macht das was sie an SlowRF kann aber etwas stabiler im Sendetiming.
CCA wird auch bei SlowRF verwendet. Das verringert Störungen anderer laufender Funktelegramme und erhöht in der Regel etwas die Schalterfolgschancen.

Außerdem sollte er bei Verwendung der a-culfw für den 433er auch das Standard CUL Modul und das Standard IT Modul für den 433er verwenden und nicht das TSCUL Modul und das IT Modul meiner Variante.

Gruß, Ansgar.

[noansi]

Hallo Zusammen,

hier https://forum.fhem.de/index.php/topic,24436.msg825473.html#msg825473 habe ich die 00_TSCUL.pm in der zip zum Code angepasst, um die oben angesprochenen CC0 = 0D / 13 log Einträge raus zu filtern.

Gruß, Ansgar.

[jw1hal]

Vorab danke für die Antworten.

Offtopic hier ist Dein 433 nanoCUL. Flashe dort bitte die a-culfw und dann ist der fine und wird voraussichtlich auch Deinen Fernseher anschalten können. Falls nicht mach einen eigenen Thread unter Anfängerfragen auf. Da helfen Wir weiter für 433!

Welches Protokoll verwendet die Funksteckdose? IT?

Da schrieb ich ja bereits:

Ich habe noch einen Fernseher über eine Funksteckdose (433 Mhz) laufen, die ich nicht in Fhem integriert bekomme.

Gut, ich hatte nicht erwähnt, dass ich mich bereits damit abgefunden habe, weil ich vermute, dass diese ein Protokoll verwenden, was gar nicht in Fhem geht.
Das waren meine erste Funksteckdosen, bevor ich Fhem und den ganzen Kram hatte. Da hatte ich eine davon fest in einem Fernseher im Kinderzimmer verbaut, damit ich mit einer Fernbedienung bei Schlafenszeit und Verbot dem Fernseher den Strom entziehen konnte. Hat immer gut funktioniert. Kind ist nicht mehr da und ich bin zu faul, das Ding wieder auszubauen. Also liegen hier 2 Fernbedienungen für den Fernseher.

Ich habe mal ein paar Bilder davon hochgeladen, weiß aber nicht, wie ich die zwischen den Text bekomme. Dann beschreibe ich es mal so. Die ZAP-Steckdosen (2 Bilder) mit der Anlerntaste hatte ich später gekauft und funktionieren (bis jetzt) auch noch nicht in Fhem.

Die anderen 5 Bilder sind von den besagten Steckdosen, wovon ich eine in dem Fernseher verbaut habe. Ich hatte da schon mehrfach sehr ausgiebig gesucht und nichts gefunden. Vermutlich funktionieren sie mit einem Protokoll, was entweder gar nicht in Fhem geht oder ich einfach nicht heraus bekommen kann, weil ich nicht die Möglichkeit dazu habe.

Aber das wollte ich hier eigentlich nicht thematisieren, hatte es nur am Rande erwähnt, mich vielleicht etwas falsch ausgedrückt und gehört ja hier nicht her.

Die 38400 ist für nanoCULs richtig, damit der USB-Seriel Interface Chip auf der nanoCUL Platine mit der richtigen Baudrate eingestellt wird.

Das werde ich die Tage nochmal probieren. So richtig habe ich über die Baudraten nichts gefunden oder an falschen Stellen gesucht. Denn gesucht hatte ich definitiv danach, eine meiner ganz vielen Fragen ...

ITSndFreq ist die Sendefrequenz für IT Befehle. Wenn Deine Dose also auf 433.92MHz auf IT Schaltbefehle lauscht, ist das richtig so.
Andere SlowRF Befehle werden von dem 433er auf 868.3MHz gesendet und generell auf 868.3MHz in der gewählte Einstellung empfangen.

Also senden die CUL´s generell da, wie es in den einzelnen Geräten angegeben ist? Ich hatte schon die Befürchtung, dass durch eine falsche Einstellung in den CUL´s sie dann generell auf der falschen, also nicht dafür vorgesehenen Frequenz senden. Denn genau dafür habe ich mir ja 2 zugelegt, damit der eine brav auf 344 und der andere brav auf 868 sendet.

Die Frequenz solltest Du beim 433er auf 433.92MHz umstellen. Das geht mit set freq 433.92 in fhem.

Das habe ich gleich mal gemacht und schon steht bei den 433er auch:

Code Auswählen Erweitern

ccconf
freq:433.920MHz freqOffs:0.000kHz bWidth:325kHz freqIF:330.08kHz rAmpl:42dB sens:12dB dRate:2.461kBit/s
agcPrio:1 agcWait:32 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0
CCAmode:0 csRelThr:14dB csAbsThr:5dB

Wenn Du den Anschluss A0 (entsprechend PortC Bit0 am Prozessor) am nanoCUL mit 150Ohm nach GND verbindest, dann sollte sich der nanoCUL mit tsculfw in der Version auch als CSM433 melden und die Frequenz auch auf 433.92Mhz als Firmwaredefault (Rücksetzen mit e) einstellen. Alternativ kann man das mit Anpasung der board.h auch fest in die Firmware reincompilieren, statt A0 mit 150Ohm nach GND zu verbinden.

Das muss ich mir mal etwas genauer anschauen, mal sehen, ob ich dazu etwas (Anleitung) finde. Ich weiß nicht, ob es auch generell sinnvoll wäre, wenn ich den 433er zum Beispiel mal wieder zurück flashen möchte. Wofür ist das eigentlich? Um die Einstellung "set freq 433.92" nicht machen zu müssen? Das macht man dann doch nur einmal, muss man eben nur wissen ... Oder hat dies jetzt einen anderen Grund? Ich gehe jetzt mal davon aus, dass wenn man den 433er mit dem TS flasht, er für 868 geflasht ist und man ihm mit "set freq 433.92" oder "150Ohm" oder "board.h" dann nach jedem Flashen die richtige Frequenz geben muss. Dann muss ich mir das einfach mal merken, macht man ja dann nur nach dem Flashen. Oder hab ich das falsch verstanden?

Außerdem sollte er bei Verwendung der a-culfw für den 433er auch das Standard CUL Modul und das Standard IT Modul für den 433er verwenden und nicht das TSCUL Modul und das IT Modul meiner Variante.

Was sind die "Standard-Module"?

Laut diesen Beitrag vielleicht 00_CUL.pm und 10_IT.pm? Die 00_CUL.pm wird mit der 00_TSCUL.pm egänzt,so dass, wenn man den 868er mit TS und den 433er mit a-culfw geflasht hat, beide CUL´s laufen können. Da aber die 10_IT.pm ausgetauscht wird, ist dies wohl nicht möglich, oder verstehe ich das falsch? Wenn dies möglich ist, bräuchte ich ja den 433er gar nicht mit Ts zu flashen, könnte ihn zurück flashen, damit er mit den IT-Dingern vielleicht mehr und bessere Möglichkeiten hat. Da weiß ich nun nicht, was das Richtige wäre.

Mit TS hatte ich es ja ursprünglich geflasht, weil die Fenstersensoren sich nicht pairen ließen. Da las ich das mit dem AES oder wie das jetzt hieß, also die Verschlüsselung, die standardmäßig aktiviert ist, was mich eben zu diesen Schritt zwang. Und als es dann Probleme gab, flashte ich auch den 433er.

hier https://forum.fhem.de/index.php/topic,24436.msg825473.html#msg825473 habe ich die 00_TSCUL.pm in der zip zum Code angepasst, um die oben angesprochenen CC0 = 0D / 13 log Einträge raus zu filtern.

Das habe ich dann auch gleich mal aktualisiert.

[noansi]

Hallo jw1hal,

Um die Einstellung "set freq 433.92" nicht machen zu müssen?

Ja. Und niemand zwingt Dich die Marker Option zu löten und somit zu nutzen.
Und lass, es, wenn Dir mein Satz Anleitung zu unklar ist.
A0 entspricht der Platinenpinbezeichung eines Nano V3.0, wie via Suche über Goggle nachzulesen.

Also senden die CUL´s generell da, wie es in den einzelnen Geräten angegeben ist?

So ist es, bzw. genau genommen solltest Du die Frequenzen mit get (ITSendFreq, get SlowRfSendFreq) erst mal beim nanoCUL auslesen, um garantiert aktuelle Werte zu sehen. Im SlowRf Modus kannst Du auch beide Frequenzen verstellen, um sie feiner an Deine Geräte anpassen zu können.
Im Homematic Modus kannst Du nur die IT-Sendefrequenz verstellen, da die für Homematic ist fest programmiert ist (nur der Frequenzoffset ist für Finetuning noch anpassbar).
Auf 344Mhz sollst Du sicher nicht senden (Schreibfehler).

Was sind die "Standard-Module"? ... vielleicht 00_CUL.pm und 10_IT.pm?

Ja, die, die Du in FHEM direkt dabei hast bzw. per Update bekommen kannst, bezeichne ich mal als "Standard".


Zu den Bildern:
Das 5. Bild mit dem HS2272C-L2 deutet auf IT hin. Vermutlich ähnlich dem PT2272, zu dem man ein Datenblatt finden kann. Dann wären der Basistakt zu ermitteln, um ITClock richtig wählen zu können und die Schaltcodes nach Beschaltung.
Ich tippe mal auf F000FFFF10 F0 F1 für die IT Schaltcodes. ITClock 224.

Gruß, Ansgar.

[jw1hal]

Ja. Und niemand zwingt Dich die Marker Option zu löten und somit zu nutzen.
Und lass, es, wenn Dir mein Satz Anleitung zu unklar ist.
A0 entspricht der Platinenpinbezeichung eines Nano V3.0, wie via Suche über Goggle nachzulesen.

Das ist das, was ich meine. Die Profi´s unter euch haben so ein Ding schön öfter gesehen, sich näher damit beschäftigt oder auch selbst gebaut. Vielleicht auch so etwas beruflich gelernt. Ich nicht, bin nur ein blöder Holzwurm, der jetzt was anderes macht. Ich hab das zum ersten Mal gesehen und vorher noch nicht gewusst, dass es das so gibt. Ich kann bissel mit nen Lötkolben umgehen, ich weiß was ein Widerstand ist, kann nach bebilderten oder auch Videoanleitungen etwas nachmachen und eventuell auch, wenn es mir logisch erscheint, nach einen Satz Anleitung etwas nachvollziehen. Dazu muss ich das aber auch alles kennen, damit ich dem allen folgen kann. Ich müsste mir den CUL nun genauer anschauen und dazu einen Stuhl nehmen, um den CUL vom Pi zu entfernen. Die Faulheit ... Dann ist da noch ein durchsichtiger Schrumpfschlauch drum, der ihn bissel schützt. Somit würde ich mich nur ensthaft näher damit beschäftigen, wenn es unbedingt sein muss und keinen anderen Ausweg gibt. Wenn ich nun täglich oder wöchentlich die Frequenz einstellen müsste, würde ich es bestimmt tun. Da ich dies aber nur nach dem Flashen machen muss und dies nicht so oft vorkommen wird, kann ich beruhigt damit leben. Ich muss auch den schönen Schrumpfschlauch nicht kaputt machen und kann auch noch selbst meine Faulheit unterstützen. Aber ich werde mir (versprochen!) den CUL mal genauer anschauen, wenn ich etwas Langeweile habe oder ihn eh mal abziehen muss. Dann werde ich hier nochmal den Beitrag suchen und diesen A0 ausfindig machen, wenn man dies durch den Schrumpfschlauch sieht. Und dann werde ich, wenn ich mal bei mir zu Hause bin, auch schauen, ob ich einen 150 Ohm Widerstand habe, um das überhaupt machen zu können, ohne jetzt extra einen bestellen zu müssen. Und den Schrumpfschlauch vom CUL jetzt extra kaputt machen, wegen nur mal Gucken, möchte ich nun auch nicht unbedingt.

Dennoch ist es gut zu wissen, dass man dies so machen kann. Danke für den Hinweis. Vielleicht überlege ich es mir ja nochmal, wenn ich es mir genauer angeschaut habe. Denn so schnell wie der Widerstand eingelötet ist, ist er ja vom Prinzip auch wieder ausgelötet.

So ist es, bzw. genau genommen solltest Du die Frequenzen mit get (ITSendFreq, get SlowRfSendFreq) erst mal beim nanoCUL auslesen, um garantiert aktuelle Werte zu sehen. Im SlowRf Modus kannst Du auch beide Frequenzen verstellen, um sie feiner an Deine Geräte anpassen zu können.
Im Homematic Modus kannst Du nur die IT-Sendefrequenz verstellen, da die für Homematic ist fest programmiert ist (nur der Frequenzoffset ist für Finetuning noch anpassbar).

Das ist auch gut zu wissen und werde ich mal probieren. Das Letztere hatte ich hier im Thred schon ein oder mehrmals gelesen.

Auf 344Mhz sollst Du sicher nicht senden (Schreibfehler).

Haha, ja da habe ich die Wechstaben verbuchselt bzw. die Zahlen. Da hat wohl das Millitär seinen Mobilfunkdienst ...

Ja, die, die Du in FHEM direkt dabei hast bzw. per Update bekommen kannst, bezeichne ich mal als "Standard".

Könnte ich dann dennoch den 433er mit a-culfw laufen lassen oder beißt sich da was, weil ja die 10_IT.pm überschrieben wird.

Zu den Bildern:
Das 5. Bild mit dem HS2272C-L2 deutet auf IT hin. Vermutlich ähnlich dem PT2272, zu dem man ein Datenblatt finden kann. Dann wären der Basistakt zu ermitteln, um ITClock richtig wählen zu können und die Schaltcodes nach Beschaltung.
Ich tippe mal auf F000FF10 F0 F1 für die IT Schaltcodes. ITClock 224.

Das ist auch sehr interessant. Ich werde es mir noch mal genauer ansehen. Vielleicht bekomme ich die Dinge ja doch noch in´s Fhem.

Danke auf Jeden Fall mal für die prompte Hilfe und einen schönen Sonntag noch.

PS: Als ich heute Morgen nach Hause kam, funktionierte alles noch, wie es sein sollte. Mit der Fernbedienung konnte ich den TV hier anschalten und Alexa schaltete mir auch die DBox2, nebst TV an, welche beide jeweils an einer Funksteckdose hängen. Also 433 ist alles OK.

[noansi]

Hallo jw1hal,

Könnte ich dann dennoch den 433er mit a-culfw laufen lassen oder beißt sich da was, weil ja die 10_IT.pm überschrieben wird.

Du kannst den 433er mit der a-culfw flashen und ihn dann wieder via

Code Auswählen Erweitern

define CUL_433 CUL /dev/CUL433@38400 0000
einbinden, also mit CUL statt TSCUL.

Bei Deinen 433er Geräten (Schaltdosen) muss das Attribut IODev auf CUL_433 gesetzt sein (oder werden, falls es nicht so ist). Ohne gesetztes Attribut wählt FHEM ein IODev aus, ohne jedoch auf die Frequenztauglichkeit zu achten, sprich der falsche IODev kann gewählt werden.

Dann nimmst Du Dir Dein Backup, dass Du sicherlicher vor Überschreiben der original Datei im FHEM Ordner gemacht hast, und kopierst daraus die original 10_IT.pm in den FHEM Ordner, überschreibst also meine Sondervariante mit der original Datei.
Sollte wider Erwarten das Backup nicht vorliegen, kannst Du auch von hier https://svn.fhem.de/trac/browser/trunk/fhem den aktuellen Stand runter laden.

Und dann bist Du mit dem 433er mit a-culfw hier auch off-topic, wie Arnd schon richtig bemerkt hat.

Gruß, Ansgar.

PS: Der Tip mit den IT Schaltcodes F000FFFF10 F0 F1 bezieht sich nur auf die Platine aus Bild 6. Wenn ich es bei der schlechten Auflösung richtig habe erkennen können.