Hallo,,
super Forum, bin auf der Suche nach eine Lösung, die es hier scheinbar schon gibt... :)
wie der Betreff schon andeutet, ich möchte meine Kopp Free control UP-Schalter und Steckdosen (insges. 12 Stück) nicht nur über die FB steuern,
ich möchte sie auch in meine "home-Made" Homeserver-Lösung integrieren.
Habe mir ein CUL nach dieser Anleitung gemacht: http://www.fhemwiki.de/wiki/Selbstbau_CUL (http://www.fhemwiki.de/wiki/Selbstbau_CUL)
Habe mir den Code (aus Sourceforge: culfw [547] und auch den alten [525] tree) heruntergeladen,
compiliert(device: nanoCul) und dann
auf den ArduinoNano geflasht... alles scheinbar ohne Probs....
Doch,
ich kann weder senden (?) noch empfangen...
Ich habe CUL mit HTERM verbunden, bei Eingabe von "V" erhalte ich:
V 1.65 nanoCUL868
bei Eingabe von "?"
? (? is unknown) Use one of B C F i A Z E k G M K U Y R T V W X e f l t x
bei Eingabe von "X08" und anschließendem drücken einer FB-Taste kommt:
rfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrfrf
m.E. nach nichts sinvolles!!!
gebe ich den Bsp.-String aus den Code kopp_fc.c ein: "kt30F96E0110000J"
erhalte ich:
Transmitt
commandlineparameter: kt30F96E0110000J
Stringlength: 16
Next Character (int) after parameter (should be line
lt. Source-Code ist hier die Ausgabe nicht vollständig... keine Ahnung warum....
was mache ich falsch... probiere schon seit Tagen und komm' nicht weiter....
liegt es evtl. an meinem Transceiver? ist der hier ungeeignet?
http://www.ebay.de/itm/400995834179?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT (http://www.ebay.de/itm/400995834179?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT)
gebe ich "krS" ein, geht der Arduino scheinbar in Empfangsmodus, aber wenn ich dann eine FB-Taste drücke, passiert nichts.
Muß ich denn an den Arduino (raw Daten) zuvor etwas schicken?
Fragen über Fragen... ich hoffe, ihr könnt mir etwas weiterhelfen....
Vielen Dank
Stef
Hi, die 1.65 Firmware für den nanuCul hat noch einen Fehler der verhindert, das Du damit FreeControl empfängst. RaspII hat in dem FreeControl Thread (http://forum.fhem.de/index.php/topic,32048.45.html) einen fix veröffentlicht.
Das cc1101 Modul ist vermutlich ein 433 MHz Modul, aber soweit ich das gelesen habe, hat das nur eine Auswirkung auf die Reichweite. Funktionieren tut das bei mir wunderbar.
Es scheint so, als wenn die Mehrzahl der cc1101 Module die als 868MHz verkauft werden, in Wirklichkeit auf 433MHz optimiert sind.
In dem o.g Thread findest Du auch viele wertvolle Infos zur implementation.
Ich hoffe das hilft erstmal.
Gruß Fd
Hallo Feuerdrache,
vielen Dank für deine Infos...
habe den Thread schon durch,
habe auch die "nanoCuL.c" bei mir gegen die von RaspII aus dem Thread ausgetauscht, compiliert und hochgeladen,
leider ohne Erfolg... bekomme einfach keinen sinnvollen Output.
hast du mal deine funktionierende Lösung einfach an einen PC mit einer Terminalemulation gehängt (z.B. HTerm)?
Was bekommst du dann beim Drücken eine Sendetaste(FB)?
Es müßte doch, nach Eingabe von "krS", etwas empfangen werden?
Gruß
Stef
Ich hab den nanoCul mittels:
make clean
make
make program
gefüllt und dann mit einem terminalprogramm Krs eingegeben
Dann kommt bei mir eine Meldung das kopp Empfang aktiviert ist.
Wenn ich dann auf der Fernbedienung eine Taste drücke kommt ein Code für Fhem. Wichtig ist, das Fhem nicht auf dem Rechner parallel läuft (aber das weist du sicher schon)
Gruß FD
Gesendet von meinem iPhone mit Tapatalk
habs, gerade nochmal probiert
make clean
make
make program
nach dem flashen im terminal "krS" eingegeben... FB-Taste gedrückt... NIX ( es kommt einfach nichts....)
gebe ich dann krE und anschließend "X08"(=vermutlich ein debug Mode?) dann erhalte ich nach drücken einer FB-Taste
rfrfrfrfrfrfrfrfrfrfrfrfrfr
ich habe auch nochmal gecheckt, ich habe dir letzte nanoCul.c (die mit den drei Zeilen) aus dem Thread
#ifdef HAS_KOPP_FC
kopp_fc_task();
#endif
habe keine FHEM auf dem Rechner....
kannst du mir mal deine nanoCuL.hex schicken?
Kommt nach KrS eine Meldung?
Hex kann ich dir morgen zukommen lassen..
Gesendet von meinem iPhone mit Tapatalk
Nee kommt keine Meldung....
was mich auch wundert:
wenn ich das Kommando aus dem Code eingebe: kt30F96E0110000J
dann kommt diese Ausgabe:
Transmitt
commandlineparameter: kt30F96E0110000J
Stringlength: 16
Next Character (int) after parameter(should be line e
das ist nicht vollständig...da wird nicht alles ausgegeben
das fehlt doch "Amount of Bytes... TickTimer ... etc...
bin so langsam am Verzweifeln..
Hallo Stoffel,
im Anhang findest Du die nanoCul.hex die ich kompiliert und auf meinem nanoCUL installiert habe.
Da ich mir sicher bin, das das CC1101 Modul was ich habe ein 433Mhz Modul ist, ist es auch eine nanoCul 433Mhz Version. Dies hat bei mir aber keine Auswirkungen auf die Funktion mit FreeControl, das ja mit 868 MhZ arbeitet.
Wenn ich mit einem Terminalprogramm mich mit den NanoCul (38400 8-N-1) verbinde bekomme ich bei Eingabe von 'V' und Enter:
V 1.66 nanoCUL433
Dann gebe ich "krS" und Enter ein:
krS-ReceiveStart
wenn ich dann eine Taste auf der Fernbedingung drücke kommt:
kr07AFFE0045CC0F044F
Da Du nicht mal das "krS-ReceiveStart" zu sehen bekommst scheint Irgendwie der nano nicht richtig zu laufen. Ich hoffe mein hex hilft Dir.
Gruß FD
Hallo Feuerdrache,
vielen Dank für dein HEX file,
hab es geladen,
leider bekomme ich hier das gleiche Ergebnis, wie bei meinen HEX files zuvor
Eingabe: V
ich erhalte: V 1.66 nanoCUL433
Eingabe krS
ich erhalte: krS-ReceiveStart
drücken einer FB-Taste: es kommt NIX
Sorry, wenn ich mich falsch ausgedrückt habe, aber auch bei meinen Versionen komme ich bis zum "krS-ReceiveStart"
das wird bei mir auch noch ausgegeben, dann aber nichts mehr beim Drücken einer Taste.
Ich habe so langsam mein CUL Modul in Verdacht, ist das evtl. defekt?
Wo stelle ich eigentlich die Baudrate im Code ein?
Bei deinem HEX file brauche ich 38400, bei meinen Versionen 19200, damit ich eine Ausgabe bekomme,
z.B. für V --> V 1.66 nanaCUL868.
Viele Grüße
Stef
Wo man die Datenrate einstellen kann weis ich nicht, gibt für mich kein Grund vom Standard abzuweichen. Dein Arduino ist ein Nano mit 16 Mhz ?
Hast du den pullup widerstand zum besseren empfangen eingebaut zwischen den Nano und das cc1101 Modul?
Gesendet von meinem iPhone mit Tapatalk
Ja, ist ein ArduinoNano 16MHz hab ich eingestellt
Widerstand? Ohh, Nee hab ich nicht...
werde ich machen...
Danke für den Hinweis...
Was hast du für ein CUL? ( China?)
Gruß
Stefan
Meine beiden cc1101 433 hab ich als 868 aus China. Meine Arduinos (hab 7 Nano, ein mini und verschiedene ATtinys hier rumfliegen) hab ich z.T. über eBay aus Deutschland und z.T. aus China, weiß ich gar nicht mehr genau welcher welcher ist.
Zwei haben einen gefälschten (beide FTDI haben die gleiche Seriennummer) FTDI USB Chip , der Rest hat den CHG340 USB Chip.
Ein NanoCUL ist mit dem FTDI Arduino auf einem Breadboard aufgebaut, der andere mit CHG340 Chip ist auf einer Platine verbaut und ist an mein produktiv FHEM angeschlossen.
Für mich wirkt das so, als wenn Dein Funkmodul entweder falsch angeschlossen oder defekt ist.
Sag bescheid, wenn ich noch helfen kann.
Gruß FD
die Befürchtung, daß ich das Modul falsch angeschlossen habe, hatte ich auch schon, daher meine Frage:
ich habe dieses Modul:
http://www.ebay.de/itm/400995834179?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT (http://www.ebay.de/itm/400995834179?_trksid=p2060353.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT)
wenn ich auf die "Lötseite"( Antenne nach rechts zeigend) schaue, dann ist am oberen linken Pin ein Rechteck, das sollte doch der PIN 1 sein, rechts davon dann PIN 2, unter dem PIN 1 ist dann PIN 3, dann PIN 5, PIN 7 und PIN 9. Rechte Reihe dann die "geraden PINs"...
Angeschlossen habe ich das Ganze nach dem Schaltplan von hier: http://www.fhemwiki.de/wiki/Selbstbau_CUL (http://www.fhemwiki.de/wiki/Selbstbau_CUL)
jetzt auch mit dem PullUp Widerstand.
Das ist doch richtig so?
Hi,
auf dem Bild kann ich leider keine Pin Beschriftung lesen. Bei mir ist auf der Platine auch eine Beschriftung.
Z.B.
Pin 1 und 2 sind VCC (3,3v)
PIN 9 und 10 sind GND
Soweit klingt Deine Beschreibung genau richtig.
Hast Du es "fliegend" verkabelt oder auf einer Plane verlötet ?
Kannst Du Fotos machen ?
Gruß FD
Wo ist bei dir der Pin1? Aussen oder auf der Antennenseite
Ja, ich habe es "fliegend" aufgebaut, wollte nicht gleich löten, bevor es nicht funktioniert...
Könnte das auch Auswirkungen haben?
ich hoffe es klappt mit dem Bild...
Moin,
die Einbelegung bei mir ist genau so wie in Gummibärs blog http://blog.gummibaer-tech.de/cul-stick-868433-im-selbstbau/ (http://blog.gummibaer-tech.de/cul-stick-868433-im-selbstbau/).
Die Pinbelegung die Du da siehst bezieht sich auf die bestückte Seite.
Soweit ich das auf Deinem Bild nachvollziehen kann ist alles richtig verkabelt.
Hast Du evt hardware für einen zweiten nanoCUL rumliegen? oder eine DVBT stick den man als Sur verwenden kann. Dann könnte man eine Fehleranalyse auf der Funkseite versuchen.
Gruß FD
Zweiten CUL hab ich noch nicht, hab mir jetzt noch einen bestellt... dauert etwas...
Ich vermute, mein aktueller CUL ist defekt....
Moin,
kann ich gar nicht glauben das der cc1101 kaputt ist.
Bin mal gespannt was Du noch so berichtest.
Falls Du die Funkseite auch angucken willst:
Ich hab mir am Anfang mal ein DVB-T Stick http://www.amazon.de/Fernsehen-Funktion-Bearbeitung-Software-Fernbedienung/dp/B00NOP0P6W/ref=cm_cr_pr_product_top?ie=UTF8 (http://www.amazon.de/Fernsehen-Funktion-Bearbeitung-Software-Fernbedienung/dp/B00NOP0P6W/ref=cm_cr_pr_product_top?ie=UTF8) besorgt, mit dem man Signale analysieren kann und ungefähr danach http://www.oe7.oevsv.at/referate/digital/sdr/RTL2832U/ (http://www.oe7.oevsv.at/referate/digital/sdr/RTL2832U/) gearbeitet.
Damit konnte ich ganz gut nachvollziehen, wie und ob meine Kopp Fernbedienung arbeitet. Damit habe ich aus rausgefunden, das meine 20 Jahre alten Funksteckdosen eine Variante von dem Intertechno Protokoll sprechen und es hinbekommen die auch noch einzubinden. :)
Gruß FD
So, zweiter CC1101 ist da,
habe ihn wie den anderen zuvor angeschlossen...
Leider ohne Erfolg, gleiches Verhalten wie der erste CC1101... kein Empfang...
an der HW scheint's also doch nicht zu liegen...
Kann es sein, daß FHEM noch eine "Initialisierung" macht, die mir bei der Terminalemulation fehlt?
Gruß
Stef
Nein, hab meine Stick auch einfach mit der nanoCulFw bespielt, Terminalemulation gestartet und krS eingegeben.
Da muss doch noch was mit der Verkabelung nicht stimmen. Oder mit dem Arduino.
Dein Arduino läuft mit 16MHz und Du verbindest dich mit 38400 Baud?
Gruß FD
Ja, meine Arduino läuft mit 16 MHZ, (Zeile ist im board.h nicht auskommentiert)
allerdings im makefile steht diese Zeile drin: F_CPU = 8000000
aber ich glaube das ist richtig so...
hab' ja jetzt zwei Arduinos und zwei CC1101... beide zeigen das gleiche Verhalten,
hatte auch die Kabel in verdacht, aber auch mit neuen Kabeln das Gleiche.
Hab ich die Pins wirkliche richtig belegt?
Wenn ich von der Bestückungsseite auf den CC1101 schaue (Antenne zeigt nach rechts)
dann ist oben links PIN1 (mit dem Quadrat)? Ist doch richtig so?
Meine Arduinos haben den CH340G USB Chip, die funktionieren in einer anderen Anwendung(RFID Reader) problemlos.
Habe mir jetzt mal die SW angeschaut...in kopp-fc.c
was hat das zu bedeuten:
* some hints:
* ===========
* - it seems, that the Firware sends the information to the display/serial interface (e.g. via DS_P() command) after this routine
* was left. That means, that nothing will displayed, when e.g, watchdog timer overruns.
* For debugging issues this is the hell :-(
* - found out, that this routine makes some courious stuff if e.g. strtol() works on wrong number base (10/16/autodetect)
mir ist ja aufgefallen, das beim Senden (z.B.: kt30F96E0110000J) die Ausgabe im Terminal abbricht, also nicht alles ausgegeben wird.
Ich habe alles unter Windows7 laufen.
Gruß
Stef
Das mit dem abbrechen der Meldung finde ich komisch, klingt für mich so als wenn noch eine andere Software versucht den Port zu nutzen, zumindest kenne ich das Verhalten, wenn FHEM auf meinem Pi noch läuft, während ich mit dem Terminal auf den Stick zugreifen will.
Pin Anschluss sah auf Deinen Bild gut aus, allerdings würde mich auf Foto von der Bestückungsseite interessieren das es verschiedene cc1101 Module gibt und die nicht unbedingt die gleiche in Belegung haben.
Zu der Software kann ich nichts sagen, aber Raspii evt.
Gruß FD
Gesendet von meinem iPhone mit Tapatalk
So, habe nochmal ein Bild von der Bestückungsseite her gemacht...( habe die Pins "beschriftet", so wie ich sie "verkabelt" habe)
ich habe jetzt auch im board.h testweise diese Zeile geändert:
#define TTY_BUFSIZE 512//128
danach bekomme ich beim Senden von "kt30F96E0110000J" die komplette Ausgabe....
jedoch meldet sich der CUL dann mit "V1.66 nanaoCUL433 obwohl die Zeile
//#define HAS_CC1100_433
auskommentiert ist.
aber Empfang geht immer noch nicht... es scheint evtl. doch an der Verkabelung zu liegen...
die Ports/Pins werden doch auch in der board.h definiert...
wie sieht denn deine board.h aus...
muss GDO2 mit D2 oder D4 verbunden werden?
Gruß
Stef
Hi,
ist schon etwa ein Jahr her, dass die die Kopp FW geschrieben habe.
Damals sind mir einige Kuriositäten aufgefallen, die habe ich im Source Code dokumentiert, dass soll aber nichts bedeuten.
Wichtig war damals, dass man die culfw zum "RESET" treiben kann, wenn sich eine Unterroutine zu lange in einer Schleife befindet. Genau das ist mir passiert, weil ich in meiner Routine "lange Tastendrücke" simuliere (siehe Timeout beim kr.... Commando).
Final möchte ich die "langen Tastendrücke" aber nicht mehr in der culfw lösen.
Ich hab mir mal angeschaut was Du sendest:
kt 30 F96E 01 10000 J
Du gibst hier ein Timeout von 10sec an.
Das sollte eigentlich nichts ausmachen, da das Timeout immer nur bei Tastencode + 0x80 (langer Tastendruck) aktiv wird, trotzdem: schicke mal 5 Nullen anstelle der 10000.
Bzgl. Baudrate: ich benutzte immer 38400, funktioniert problemlos.
Bei meinen Tests (umschalten zwischen Terminal und FHEM) hatte ich mal ein ähnliches Problem wie Du (mein CUL hatte nur unvollständig oder kompletten Schrott geantwortet ).
Ich habe dann den RASPII runtergefahren und sowohl RASPII wie auch CUL von der Versorgungsspannung getrennt. Danach das System wieder hochgefahren.
Danach hat alles wieder ganz normal funktioniert. Ich habe nie rausbekommen was die Ursache war.
Wichtig:
neben dem KOPP Prototokoll darf dem nanoCUL kein weiteres Protokoll zugewiesen werden.
Gruß
RaspII
Hab mir jetzt nochmal die FW angeschaut. Die Meldung sollte eigentlich wie folg lauten:
ZitatNext Character (int) after parameter (should be line end character)
Jetzt könnte folgendes passiert sein:
Die Textausgabe könnte zu lange daueren, d.h. dazu führen, dass der Watchdog der culfw aktiv wird und einen Reset auslöst.
Das würde aber bedeuten, der Watchdog Deines nanoCULs hat einen kürzeren Zyklus wie beim Standard CUL.
@Feuerdrache: hast Du das auch mal bei Dir ausprobiert (ein RAW Commando mit J am Ende senden)
@stoffel: was passiert eigentlich wenn Du folgendes Kommando schickst:
kt30F96E0100000NKannst Du diesen Befehl dann einem Kopp Aktuator anlernen?
Hallo RaspII, Hallo Feuerdrache,
bin jetzt schon mal einen Schritt weiter....habe ja jetzt zwei ArduinoNano + CUL-Module... beide geflasht und an zwei Rechner angeschlossen.
auf beiden Rechnern "HTerm" gestartet und verbunden.
auf der einen Seite gebe ich folgendes ein:
Zitatkt30F96E0100000N
auf dem anderen Rechner kommt folgendes:
Zitatkr07F96E0930CC0F01C1
kr000000000000000000
kr07F96E0930CC0F01C1
kr000000000000000000
kr07F96E0930CC0F01C1
kr000000000000000000
kr07F96E0930CC0F01C1
kr000000000000000000
kr07F96E0930CC0F01C1
kr000000000000000000
kr07F96E0930CC0F01C1
kr000000000000000000
kr07F96E0930CC0F01C1
kr000000000000000000
kr07F96E0930CC0F01C1
kr000000000000000000
kr07F96E0930CC0F01C1
kr000000000000000000
kr07F96E0930CC0F01C1
kr000000000000000000
kr07F96E0930CC0F01C1
kr000000000000000000
kr07F96E0930CC0F01C1
kr000000000000000000
kr07F96E0930CC0F01C1
kr000000000000000000
das sieht doch schon mal gut aus, es scheinen also beide CULs zu funktionieren!
ob das stimmt/richtig ist, was da ankommt, kann ich nicht sagen...
müßte nicht genau der Sendestring mehrmals ankommen?
Und damit kann ich auch keinen Aktuator anlernen,
habe hier eine Funksteckdose ( meine UP-Aktoren sind alle UP-verbaut, da komm ich nicht so leicht ran).
und eine 5*8 FunkFernbedienung(811402), diese möchte ich "nachbilden".
mit der Fernbedienung kann ich anlernen, da schaltet die Steckdose,
mit dem o.a. Befehl
Zitatkt30F96E0100000N
geht's leider nicht, da reagiert die Steckdose gar nicht.
Große Frage, warum nicht?
Hi,
hm, so richtig gut sieht das nicht aus.
kr000000000000000000
Hab ich noch nie gesehen, dürfte nicht kommen (könnte aber auch ein SW Fehler sein, ich schau da nochmal rein).
Wenn Du aber nichts beim Tastendruck auf die Fernbedienung empfängst funktioniert was Grundlegendes nicht.
Ich habe in einem anderen Thread gelesen, dass jemand zwar 2 CC1101 Module miteinander koppeln konnte, nicht aber mit FS20 Komponenten kommunizieren konnte. Am Ende hat sich dann herausgestellt, dass die CC1101 Module die Frequenz nicht halten (also beide auf der falschen Frequenz gesendet/empfangen haben).
Aber zumindest scheint klar zu sein, dass Du alles richtig miteinander verbunden hast.
Die Sendebotschaft und der Empfangsstring sind tatsächlich unterschiedlich aufgebaut, ich hatte eigentlich nie vor mit Roh Daten zu arbeiten (würde ich beim nächsten mal anders machen).
Mich stimmt das ganze jetzt zuversichtlich, ich gehe davon aus, dass die neuen Module funktionieren (mit diesen Modulen hatte noch nie jemand Fehler gemeldet, mit den blauen gibt es zumindest bei 868Mhz viele Anwender die Probleme melden).
Mein Vorschlag: Abwarten bis ich die Module getestet habe, ich befürchte ansonsten ist die Zeit umsonst investiert.
Wenn ich mal Zeit habe messe ich nach ob der Quarz am CC1101 Modul auf der richtigen Frequenz läuft.
Hab gestern bei Aliexpress gestöbert, und festgestellt, das bei vielen "blauen" Modulen in der Beschreibung steht das sie nicht bis 868MHz gehen. Daher ich denke ich, das es nicht nur die Antennenbeschaltung der Module ist, die bestimmt, ob sie bei 868 MHz gut funktionieren...
Na mal sehen.
Gruß FD
So, bin ein gewaltiges Stück weiter.... ;D
die "blauen" senden nicht auf der eingestellten Frequenz....
Dank Feuerdrache (ich habe keine Kosten und Mühen gescheut) habe ich mir einen DVB-T Stick besorgt(siehe Link oben)
den Stick ans Laufen zu bekommen ist ein anderes Thema (ich könnte k... >:( >:( >:()
damit habe ich die Differenz zwischen Kopp FB und dem CUL sichtbar machen können.. Hurra!!!!
Habe dann in der Kopp_fc.c die Frequenzwerte angepasst:
0x21, // 0D FREQ2 *1E 21 21 FREQ[23..0] = f(carrier)/f(XOSC)*2^16 ->
0x66, // 0E FREQ1 *C4 65 65 s.o.
0x78, // 0F FREQ0 *EC e8 6A s.o.
neu kompiliert und geflasht.... und siehe da...
ich kann die Steckdose anlernen, und bekomme auch bei "krS" un ddrücken der FB folgende Ausgabe:
Zitatkr0788101B01CC0F02EE
kr000000000000000000
kr0788101B01CC0F02EE
kr000000000000000000
kr0788101B01CC0F02EE
kr000000000000000000
kr0788101B01CC0F02EE
kr000000000000000000
kr0788101B01CC0F02EE
kr000000000000000000
kr0788101B01CC0F02EE
kr000000000000000000
kr0788101B01CC0F02EE
kr000000000000000000
kr0788101B01CC0F02EE
kr000000000000000000
hier komischerweise nur 8x jede Zeile???
Mit der Software scheint wirklich etwas nicht zu stimmen,
bei mehreren FB Tasten drücken kommt hin und wider auch mal ein
Zitat40 Checksum Error
siehe screenshot unten... vor der Frequenzanpassung war der rote Block(CUL) weiter links... bei ca. 868,171Mhz
durch die Anpassung ist er nun im gleichen Bereich wir der schwarze Block (Kopp FB) bei 868,229MHz
rechnerisch eingestellt ist aber jetzt 886,407Mhz
hoffe das hilft euch auch weiter...
:D
Gruß
Stef
Hi, coole Arbeit.
Gruß FD
Gesendet von meinem iPhone mit Tapatalk
Hi,
aber ohne eure Hilfe wäre ich niemals so weit gekommen...Vielen Dank
habe gerade versucht, meine Aktuatoren anzusteuern,
leider auch hier wieder ohne Erfolg,
schalten kann ich aktuell nur die Kopp Funksteckdose,
die Akuatoren reagieren garnicht, vermutlich zu schwaches Sendesignal...(siehe Screenshot, schwarz Kopp FB, rot CUL)
die FB kann ich problemlos empfangen, wenn ich aber dann den Code mit dem CUL sende, passiert nix...
Hat einer von euch eine Idee??
Gruß
Stef
Wenn es ein schwaches Signal wäre müsste es reichen den cul nahe an die aktuatoren zu bringen.
Gruß FD
hab ich probiert, bringt nix...
mußa´also was anderes sein...
Hi,
die Kopp Empfänger reagieren extrem kritisch auf die Frequenzkonfiguration..
Ursprünglich hatte ich per RFM12B gesendet und laufen Probleme gehabt.
Erst mit den CC1101 und korrekter Konfiguration hat's dann zuverlässig funktioniert.
Stoffel: kannst Du mir das mit dem DVB-T Stick erklären?
Wo steht wie es geht?
Ich bin eben vom Urlaub zurück, ab morgen kann ich besser auf Eure Fragen eingehen und evt. Meine SW anschauen.
Jeder Kopp Block wird 13x gesendet. Aber Blöcke mit Nullen darf es eigentlich nicht geben.
Hi Raspii
Ich glaube Stoffel bezieht sich hier drauf:
Zitat von: Feuerdrache am 07 Februar 2016, 12:28:23
Falls Du die Funkseite auch angucken willst:
Ich hab mir am Anfang mal ein DVB-T Stick http://www.amazon.de/Fernsehen-Funktion-Bearbeitung-Software-Fernbedienung/dp/B00NOP0P6W/ref=cm_cr_pr_product_top?ie=UTF8 (http://www.amazon.de/Fernsehen-Funktion-Bearbeitung-Software-Fernbedienung/dp/B00NOP0P6W/ref=cm_cr_pr_product_top?ie=UTF8) besorgt, mit dem man Signale analysieren kann und ungefähr danach http://www.oe7.oevsv.at/referate/digital/sdr/RTL2832U/ (http://www.oe7.oevsv.at/referate/digital/sdr/RTL2832U/) gearbeitet.
Damit konnte ich ganz gut nachvollziehen, wie und ob meine Kopp Fernbedienung arbeitet. Damit habe ich aus rausgefunden, das meine 20 Jahre alten Funksteckdosen eine Variante von dem Intertechno Protokoll sprechen und es hinbekommen die auch noch einzubinden.
Gruß FD
Gesendet von meinem iPhone mit Tapatalk
Hi,
ich habe mir das ganze jetzt mal bei mir angeschaut (auf einem CCD und CUL-V3):
Tippe ich krS ein, kommt wie erwartet:
krS-ReceiveStart
Danach drücke ich 2 unterschiedliche Tasten in folgender Reihenfolge: Taste 1, Taste 2, Taste1 und bekomme folgende Ausgabe:
kr07F1295030CC0F01D7
kr07F1295120CC0F01C6
kr07F1295230CC0F01D5
Splittet man die Blöcke wie folg auf:
kr07 F129 50 30 CC0F 01 D7
kr07 F129 51 20 CC0F 01 C6
kr07 F129 52 30 CC0F 01 D5
sieht man den Tastendruckzähler von 50, 51, 52 wandern
Der Tastencode ist 30, dann 20, dann wieder 30.
-> Dein Problem muss am nanoCUL oder CC1101 Modul liegen.
Nachtrag:
Hab mir nochmal meinen Code angeschaut.
Mir ist völlig unklar, wie folgende Botschaft rausgehen kann:
kr000000000000000000
Eigentlich müsste eine Empfangsbotschaft mit lauter Nullen spätestens bei der Checksummenprüfung rausgefilter werden.
Das erklärt dann auch warum jede Botschaft 13 x übertragen wird.
Meine Software "meldet" einen empfangen Block nur dann wenn dieser sicht geändert hat, identische Blöcke werden unterdrückt (das bedeutet nur 1x übertragen, da auch der Tastendruckzähler nicht verändert wurde).
Bleibt nur die Frage woher der Block mit den "Nullen" kommt.
Den kann ich mir beim besten Willen nicht erklären.
Nachtrag 3.4.2016
Nach zigmaligem Codereview muss ich leider gestehen, ich kann mir das jetzt doch erklären.
Wenn ein HW Fehler vorliegt (der GD02 Pin ist falsch verdrahtet) können derartige Botschaften entstehen.
Meine Empfangsroutine gibt dann einen Block aus, obwohl 0 Bytes empfangen wurden.
Dieser Block ist ein "Null Block", da der Empfangsbuffer per default mit "0" initialisiert wird. Ich habe die culfw inzwischen verbessert. Habe eben aber festgestellt: theoretisch können noch immer falsche Blöcke empfangen werden wenn die Verdrahtung falsch ist (allerdings nur extrem selten, wenn gleichzeitig auch ein Kopp Sender aktiv ist).
Ich richte das mal bei Gelegenheit.
Hallo Raspi,
Feuerdrache hat es schon geschrieben, habe mir den DV-T stick geholt (15€)....
War etwas "tricky" den zum Laufen zu bringen...
Bei mir kommen nach wie vor die 2x13 Pakete jeweils immer mit den "0000000000" dazwischen...
Bin aktuell nicht Zuhause, kann also nicht nachschauen...
Gruss
Stef
Ein neuer DVB-T Stick ist schon bestellt :) (ein bereits vorhandener hat den falschen Chip).
Ich könnte in der Kopp Firmware versuchen "Testweise" das Ausgeben der Nullen zu unterdrücken, damit könntest Du mal weitertesten.
Als echte Lösung halte ich davon aber nichts, da das Problem noch nicht verstanden ist.
Melde Dich wenn Du mal wieder am PC bist, am besten wir machen as "Online" (ich ändere, Du kompilierst für den nanoCUL)
Hallo stoffel,
ich würde gerne noch teos Fragen künftig in Deinem (diesem) Thread besprechen wollen.
Es geht um die selbe Fragestellung: nanoCUL, blaues CC1101 Modul und Kopp Protokoll.
Bisher habe ich "zweigleisig" supportet, macht aber eigentlich keinen Sinn.
Mein bisheriger Thread incl. teos derzeitigen Status:
http://forum.fhem.de/index.php/topic,32048.120.html#lastPost (http://forum.fhem.de/index.php/topic,32048.120.html#lastPost)
ok für Dich?
Gruß
RaspII
Ja ist Ok,
Ist dann übersichtlicher....
Gruss
Stef
Mir sind momentan die Hände gebunden, habe jetzt auf Homematic umgerüstet. Werde hier Aktiv bleiben und beobachten ob ihr die Fehler findet.
Habe alles nach Plan befolgt aber ich habe leider auch nicht die große Erfahrung selber den Fehler zu finden...
@stoffel
ich hab den DVB Stick jetzt auch (RTL2832U)
Bekomm das aber nicht zum laufen, obwohl ich dieser Anleitung gefolgt bin:
http://www.oe7.oevsv.at/referate/digital/sdr/RTL2832U/ (http://www.oe7.oevsv.at/referate/digital/sdr/RTL2832U/)
Was genau meintest Du mit:
ZitatWar etwas "tricky" den zum Laufen zu bringen...
was war zu tun?
Gruß
RaspII
Auf welchem os machst du das? Windows 7?
Gruß FD
Win7 64Bit
Gesendet von meinem SM-G900F mit Tapatalk
Hallo zusammen,
hab eben nochmal nachgeguckt, der Link den ich oben eingebaut habe, führt zu einer uralten Version von SDR#.
Hier ist ein Link zu einer Anleitung mit besseren Links um SDR# zu laufen zu bekommen.
http://www.rtl-sdr.com/rtl-sdr-quick-start-guide/
Ich nutze die SDR# Version 1.0.0.1337. alles danach sollte funktionieren.
Als Einstieg habe ich einfach mal versucht den bei mir stärksten Radiosender zu empfangen..
Gruß FD
Ok,
kaum macht man's richtig schon klappts ;D (hätte mir heute einige Stunden Recherche und Installationsorgie sparen können)
Die alte Anleitung klappte nicht (passte wohl nicht zu den neueren Versionen).
Bei mir senden alle Kopp Sender auf ca. 868,25 Mhz, auch mein CUL.
Mein verbliebenes 433 Mhz Modul kann ich nicht mehr testen, ich hab mir den Sparkfun Pro Micro zerflasht.
Hab zwar noch einen, den muss ich aber vermcutlich als ISP Programmer nutzen, d.h. den will ich nicht auch noch killen
Aber das kannst Du die nächsten Taqe dann nahholen.
(Muss mir nur noch überlegen ob ich das Hobby wechsle. Wollte eigentlich schon immer Amateurfunk machen, das Tool ist echt genial)
Dank Dir für die Hilfe.
RaspII
Hallo RaspII,
habe den Eintrag erst jetzt gelesen.... Sorry...
jetzt weißt du auch warum ich von "tricky"... geschrieben habe... wenn man's gleich richtig macht geht's... :)
das Ding ist wirklich gut, allerdings braucht man scheinbar eine "vernünftige" Antenne, die fehlt mir noch...
aber die Frequenzen 433 und 868 und "drumrum" kann man damit schon sehen...
konntest du dir schon die Sourcen anschauen, warum kommt da immer "kt00000000"... zwischendurch?
habe aktuell etwas Probleme mit einen Kopp Schaltern, einer nach dem anderen gibt den Geist auf...
d.h. er reagiert nicht mehr auf Funksignale und läßt sich auch nicht "resetten", LED blinkt einfach nur....
Gruß
Stef
Hallo Stef, dazu hab ich hier irgendwo im Forum mal was gelesen. Hatte mit einem Kondensator zu tun der gealtert ist, wenn ich mich richtig erinnere.. Kann gerade nicht suchen.
Gesendet von meinem iPhone mit Tapatalk
Hallo Feuerdrache,
das kann sein,
hab mal so einen Aktor aufgemacht, da ist auf der 230V Seite nicht viel,... neben dem Relais ein gelber Kondensator
MPX40/100/21... ??? könnte der defekt sein?
Hi,
kannst Du bei dem Schalter noch alle angelernte Fernbedienungen zurücksetzen?
Falls ja, liegt Dein Problem vermutlich am 433 MHz Modul.
Wenn das Modul Schrott beim Empfangen macht, ist Schrott beim senden nicht auszuschließen.
Ich melde mich heute Abend nochmal
Gesendet von meinem SM-G900F mit Tapatalk
Hallo stoffel,
bzgl.
Zitatkonntest du dir schon die Sourcen anschauen, warum kommt da immer "kt00000000"... zwischendurch?
Ich hab Dir mal ein modifiziertes Kopp Modul eingebaut.
Dieses Modul sollte empfangene Botschaften nur noch weitergeben, wenn der Blocklängenzähler = 7 ist.
D.h. Du solltest je Tastendruck nur noch eine Botschaft sehen.
Ich habe das Modul bei mir grob angetestet (keine Probleme finden können), wäre schön wenn Du es Zeitnah für den nanoCUL übersetzen kannst.
Das löst aber vermutlich das Problem noch nicht.
Irgend etwas in der Kombination nanoCUL und 433Mhz Modul ist oberfaul.
Derartige Probleme habe ich auf einen original CUL / CCD Modul noch nie gesehen (ich teste mit beiden).
Haben Deine Kopp Schalter/Aktuatoren begonnen zu spinnen nahdem du mit dem nanoCUL gesendet / angelernt hast oder hast Du das mit der normalen Fernbedienung hinbekommen?
Nachtrag:
Ist an Deinem Modul der GDO2 Pin verdrahtet?
Gruß
RaspII
Ach ja,
und so sieht das Spektrum verschiedener Kopp Sender aus.
Gruß
Hei RaspII,
da haben wir Zeitgleich das gleiche gemacht :-)
Anbei das Wasserfalldiagramm der drei Sender die ich hier habe. dabei fällt auf, das mein "grünes" cc1101 Modul (Beschriftet RF1101SE-V3.1) auf einem breiteren Spektrum als die original Fernbedingung sendet. Das blaue cc1101 Modul von RaspII (Beschriftet mit RF1100SE) senden um 0,2Mhz zu niedrig.
Mir ist aufgefallen, das die Beschaltung des blauen Moduls in einigen Feinheiten von der des grünen abweicht.
Ich sehe mal die nächsten Tage, ob ich es schaffe, mir eine culfw zu bauen, die die Frequenzabweichung berücksichtigt und mir der Probieren, ob ich sie dazu bekomme mit meinem grünen Modul zu reden.
Soweit erstmal...
Gruß FD
Nachtrag: Das Grüne Modul hat einen cc1101l verbaut, während das blaue einen cc1101 hat. Quarz ist bei beiden 26Mhz.
Hallo RaspII,
habe deine kopp-fc.c eingebaut.
Um mit meinem CuL etwas zu empfangen mußte ich aber wieder die Frequenz anpassen. siehe Bild
Beim Empfang bekomme ich jetzt nur noch eine Zeile,
Zitatkr0788106C71CC0F02E9
das ist jetzt richtig, allerdings habe ich auch immer wieder zwischendurch
Zitat64 Checksum Error
und das Senden macht jetzt auch Probleme, es geht eine Weile, dann kommen nur noch
ZitatTX_INIT_ERR_01
dann geht's erst wieder nach einem Reset!
GD02 Pin ist verdrahtet auf Arduino Pin 2
Gruß
Stef
PS:
habe jetzt festgestellt, die "Checksum Error" kommen nur, wenn ich eine Taste der FB "länger" drücke...
Hi nochmal,
GDO2 muss
CC1100_IN_PORT /CC1100_IN_PIN
zugewiesen sein und als Eingang konfiguriert sein.
Ich kann mir als Fehlerquelle derzeit nur diesen Pin erklären, der könnte die Empfangs- und Sendeprobleme erklären.
Ansonsten müssen wir über Printausgaben debuggen.
Ich kann heute Abend evt. ab etwa 20:00 eine Debugsession machen. Sag Bescheid ob du auch Zeit hast.
Wenn du den FB Taster fuer längere Zeit drückst, wird beim Drücken der Tastencode +0x80 13x gesendet, beim loslassen kommt dann 3x ein Block mit Tastencode 0xF7
Ckecksummenfehler gibt es mit CUL nie (laut meinen Logfiles)
Hast Du einen Oszi verfügbar?
GD02 zuweisen erfolgt doch in der board.h
Zitat/* CC1101 GDO2 Rx Interrupt */
#define CC1100_IN_DDR DDRD
#define CC1100_IN_PORT PIND
#define CC1100_IN_PIN PD2
#define CC1100_IN_IN PIND
da ist nichts geändert...
wie kann ich die Tastendrücke "sichtbar" machen?
Oszi hab ich keins.
Per Terminal auf den nanoCUL gehen. FHEM vorher runterfahren
Danach im Terminalmode Programm "krS" eingeben
Dann solltest du nach einem Tastendruck jeden Block mindestens 1x sehen.
Wenn Du auch einen CUL-V3 hast, am besten mit dem CUL anfangen (vorher mit neuster FW flashen)
Dann siehst Du das Sollverhalten
Gesendet von meinem SM-G900F mit Tapatalk
P.s. Arduino/nanoCUL Pin2 ist PD2? (hab kein Datenblatt )
Hast Du evt. das Ti RF-Studio incl. Hardware?
genauso mach' ich's die ganze zeit,
hab' kein FHEM, ( habe eine Home-AutomationEigenentwicklung)
verbinde immer mit HTERM unter Win7, sieht dann so aus: siehe screenshot
was mir auffällt:
bei kurzem FB Druck stimmt die Ausgabe: key:71 ( drücke die 8.Taste auf Ebene 1)
bei langem FB Druck kommt zuerst E1 dann F7, müßte das nicht immer gleich sein?
Ti RF Studio habe ich nicht.
Nein,
Der erste Block ist die gedrückte Taste plus 0x80 (das bedeutet dann die Taste wird lang gedrückt), der zweite Block mit F7 sagt: jetzt wurde die Taste wieder losgelassen. Das wird z.B. für Dimmer benutzt
Gesendet von meinem SM-G900F mit Tapatalk
mein Kopp UP Schalter, den ich zu testen ausgebaut habe scheint wirkich defekt zu sein...
reagiert nicht mehr, auch wenn ich ewig lange den Reset-Knopf drücke....
die anderen UP-Aktoren die ich noch eingebaut habe schalten nur mit der FB.
wenn ich mit dem NanoCUL einen weiteren schalten will, dann schaltet nur meine Funksteckdose aber nicht der UP-Aktor.
die Funksteckdose schaltet seltsamerweise immer, egal welchen Key-Code ich verwende... das ganze wird immer suspekter.
Opps,
habe den falschen Key-code eingeben,
trotzdem schalten die UP-Aktoren einfach nicht mit dem CUL nur mit FB.
Hi,
sind die UP Aktoren in der Wand eingebaut?
Dann wird ein Reichweitenproblem mit den 433 MHz Modulen sein
Gesendet von meinem SM-G900F mit Tapatalk
So, bin jetzt zuhause.
Falls Du Zeit hast könnten wir mal versuchen zu debuggen.
Am besten denke ich per Skype - Audio (keine Kamera bereit).
Falls ja, schick mir am besten eine private Nachricht mit Deinem Skype Namen.
Ich schau schon mal nach wie man den Code am besten verwanzen kann.
@Feuerdrache:
Siehst Du die selben Effekte wie stoffel?
Gruß
RaspII
ich habe 5 der Aktoren in einem Gehäuse (Gartenbewässerung), die sind jetzt seit Sept. inaktiv
habe Sie vorhin mal wieder angeschaltet.. es scheinen auch hier nur noch 3 zu funktionieren....
die anderen sind "richtig eingebaut", Licht und Pumpensteurung Garten, mit denen möchte ich nicht experimentieren....
Nun auch einmal hier, damit nicht bei anderen Verwirrungen auftreten.
Hatte nur einmal eine Nullbotschaft gehabt, als ich das Funkmodul abgezogen habe. Daher würde ich auch eine schlechte Verbindung tippen.
Gruß FD
Hi,
stoffel und ich haben erstmal beschlossen, dass wir mit den 433 Mhz Modulen nicht weitermachen.
@Feuerdrache: setzt Du diese Module inzwischen produktiv ein, d.h. läuft das zuverlässig)?
Dann würde mich noch interessieren, ob Du die neue kopp-fc.c von gestern für die Tests genutzt hast oder noch das Modul das die
"Null Botschaften" nicht wegblendet.
Gruß
RaspII
Ich setzte den nanocul schon länger produktiv ein. Und seit 19.1. auch mit Empfang, also auch mit der software von damals git version (547 kann das sein?). Hab eine version ohne das wegblenden.
Also mit einer Kopp Fernbedienung wird z.B. Eine LED leuchtband über das wifilight Modul gesteuert. Das funktioniert ganz gut, nur manchmal hängt sich der nanocul auf , dann blink die sende Lied ganz hektisch. Hab aber die Vermutung das das mit dem eingesparten Levelshifter zu tun haben könnte, hab aber noch kein Systems gefunden, mit dem ich das provozieren kann.
Gruß FD
Das blaue 433 Modul würde ich auch nicht produktiv einsetzen, bedeutet zu viele Kompromisse. Hab mit meinen beiden Glück gehabt, aber glaube das das rf1001se-v3.1 ganz gut funktioniert. Link hatte ich ja gepostet.
Hi Stoffel,
noch ein Nachtrag:
Auf Seite 4 hast Du ein Terminalausdruck drauf.
Was da wirklich kurios ist:
Falls Du tatsächlich die selbe Taste mal kurz und mal lang gedrückt hast geht etwas völlig schief.
71 ist der Code für den kurzen Tastendruck
d.h.
F1 müsste dann der Code für den langen Tastendruck sein (+80H)
Bei Dir ist das aber E1, das kann so nicht sein.
Oder hast Du hier verschiedene Tasten gedrückt?
Hab es mal mit dem großen Sender bei mir nachvollzogen (Taste 8, Rad1), Ergebnis:
kr07FA5E6071CC0F02D9
kr07FA5E61F1CC0F0258
kr07FA5E62F7CC0F025D
kr07FA5E63F7CC0F025C
D.h.
kr07FA5E 60 71 CC0F02D9
kr07FA5E 61 F1 CC0F0258
kr07FA5E 62 F7 CC0F025D
kr07FA5E 63 F7 CC0F025C
F7 ist dann das Schalter losgelassen Kommando, wird von meinem Modul zwei mal weitergereicht, da sich der Tastendruckzähler ändert (62->63).
Noch etwas das ich mir absolut nicht erklären kann.
Es sei denn es gab bei der Firmware der Sender mal einen Bug :-)
So als letztes für heute.
Anbei noch ein Excel Sheet zum Ermitteln von Checksummen etc.
Vorsicht!
Man muss die Macro's aktivieren, es könnte jemand manipuliert haben.
Also nur von hier laden, da kann (soweit mir bekannt) auch nur ich was ändern
Gruß
RaspII
Hallo RaspII, du warst aber noch lange aktiv!!!
ich kann nicht mehr genau sagen, was ich da gedrückt habe...
habe es jetzt nochmal kurz nachgespielt, analog zu deinem Bsp.
Rohdaten:
einmal kurz und dann einmal lang gedrückt
kr078810FB71CC0F027E
kr078810FCF1CC0F02F9
EA Checksum Error
kr078810FDF7CC0F02FE
kr078810FEF7CC0F02FD
93 Checksum Error
formatiert:
kr078810 FB 71 CC0F027E
kr078810 FC F1 CC0F02F9
kr078810 FD F7 CC0F02FE
kr078810 FE F7 CC0F02FD
sieht also aus wie bei dir, und scheint daher zu passen :)
ich habe nach wie vor diesen Checksum Error, und zwar immer nur wenn ich lange drücke,
dann kommt die erste Zeile, dann der Error und dann zwei weitere Zeilen....und wieder Error
vielleicht kannst du damit was anfangen...
@Feuerdrache...du scheinst' wirklich Glück zu haben ;)
... habe selbst auch schon einen Levelshifter und Pullup Widerstand eingebaut, aber immer der gleiche beschriebene Effekt...
so, muß nun weg....
Kommt die Fehlermeldung vor dem Loslassen der Taste?
Gesendet von meinem SM-G900F mit Tapatalk
ich drücke eine Taste
es kommt die erste Zeile und direkt der Checksum Error
weiter erst mal nix...
ich lasse die Taste los...
es kommen die zwei weiteren Zeilen und dann wieder der Checksum Error
Ok,
Dann kommt danach irgendwoher Schrott.
Schau ich mir bei Gelegenheit mal an.
Gesendet von meinem SM-G900F mit Tapatalk
Hi,
@Stoffel:
kannst Du mir bitte noch einen Link auf Deine aktuelle nanoCUL Firmware schicken.
Wenn ich am Wochenende Zeit habe baue ich Dein Setup doch noch bei mir auf.
Gesendet von meinem SM-G900F mit Tapatalk
Hallo RaspII,
habe eigentlich nur im aktuellen "trunk" 549 die Datei kopp-fc.c angepasst. (Frequenzanpassung für die blauen CC1101)
Viel Spaß am WE ;)
Gruß
Stef
Ok,
und ich hab mir gestern abend den nanoCUL gekillt :-(
Mal sehen ob ich das kurzfristig hinbekomme.
Gesendet von meinem SM-G900F mit Tapatalk
Sodele, ein paar Neuigkeiten habe ich.der nanoCUL ist immer noch defekt >:( ,kommt davon wenn man schnell schnell macht (hudelt).
Dafür konnte ich jetzt endlich den ProMicro wiederbeleben (nachdem ich den Bootloader vom Nano draufgeflasht habe, konnte man ihn wieder ansprechen, keine Ahnung warum der falsche Bootloader funktionierte, der richtige aber nicht). Nachdem der falsche Bootloader lief musste ich noch den richtigen Bootloader flashen, danach ein leeres Arduino Projekt laden, danach liefs wieder.
Ich hab die
kopp-fc.c von stoffel (mit angepasster Frequenz) genommen und siehe da, ich kann das Kopp Protokoll empfangen und senden,
d.h. die Frequenz Abweichungen sind zumindest stabil.
Das Modul versteht den Kopp Sender, der Kopp Dimmer versteht das Modul.
Allerdings: jämmerliche Reichweite und viel zu breites Spektrum.
Aber zumindest läuft mein System, die Verdrahtung hatte gestimmt. Danke an alle, der Tipp bzgl.
SDR war Gold wert (man sieht sofort wo das Problem liegt).
Stoffel, Dich muss ich entäuschen, bei mir gibt es keine Checksummenfehler, alles läuft wie erwartet (bis auf die ebenfalls erwarteten Reichweiteprobleme).
Sobald mein nanoCUL wieder läuft (Ersatzteile sind bestellt), schau ich nochmal nach Dein Fehler bei mir reproduzierbar ist.
Allerdings muss man solche Effekte fast erwarten, wenn man einen 5V CUL mit einem 3,3V CC1101 Modul koppelt (der CC1101 muss höhere Ströme/Stromspitzen ertragen, das liegt ausserhalb der Spec).
Jetzt noch ein Hinweis:In meinem System mit Pro Micro ist / bleibt wohl der
Arduino Boot Mechanismus aktiv (2x Reset drücken um in den Boot Mode zu kommen).
Ob der CUL Bootmechanismus zusätzlich aktiv ist, kann ich nicht bewerten, da bei mir der HWB Schalter nicht verbaubar ist (Signal ist fest auf Masse beim
Pro Micro).
Das ich die letzten Tage nicht weitergekommen bin lag daran, dass die culfw inzwischen wohl so groß geworden ist, dass diese nicht mehr gemeinsam mit dem Arduino Bootloader auf den m32u4 passt.Ich hatte deshalb beim Programmieren immer verify Error bekommen und die culfw ist danach abgestürzt. Nachdem ich jetzt ein paar Module aus dem Makefile entfernt habe läuft das alles.
Wie geht es jetzt weiter:
- Nachdem der nanoCUL m.E. kein richtig tauglicher Proband ist, auch der Pro Micro basierte CUL passt nicht so richtig, da man nicht an alle Signale kommt (HWB Schalter) suche ich nach einer Lösung mit 3,3Volt/8 Mhz 32u4 (am besten eine Breakout Version bei der alle Pins auf Pfostenstecker gelegt sind).
Bisher habe ich nur Module teurer 20€ gefunden, falls jemand einen günstigeren Tipp hat, nur her damit.
Bis dahin überlebe ich mit dem ProMicro und nutze solange halt den Arduino Bootloader (scheint ja halbwegs stabil zu laufen) - Dann warte ich noch ab wie sich die bestellten 868 Module verhalten, läuft das alles positiv beschreibe ich die Lösung hier bzw. in einem neuen Blog
Habe noch meine Schaltung angehängt
RaspII
Hi,
heute ist mein neues CC1101 Modul (Briefmarke, echte 868Mhz) gekommen.
Habs angeschlossen, die Frequenzeinstellungen für das Kopp Protokoll in der culfw wieder auf den Originalwert gesetzt.
Kaum zu glauben, alles lief auf Anhieb.
Anbei noch meine Schaltung
RaspII
Hallo zusammen,
ich hab noch etwas mit dem blauen 433 Mhz Modul geforscht.
Dazu hab ich es bei 433 Mhz in Betrieb genommen, meine 433 Mhz Funksteckdosen kann ich damit auch steuern.
Allerding sehe ich auch hier eine Frequenzabweichung von ca. 120khz, d.h. etwa die hälfte der Abweichung die wir bei 868 Mhz sehen (Soll Frequenz ist 433.920Mhz). Der Handsender (Bild Mitte) sendet auf der korrekten Frequenz)
Ich vermute mal das ist der Quarz, mal schaun ob ich das auch noch messtechnisch klären kann (mal sehen was der China Oszi taugt)
Klar ist nur, dass ich keine weiteren "blauen" Module mehr kaufen werde.
Bei meinen Untersuchungen habe ich auch rausbekommen, das der Port / Pin:
#define MARK433_PORT PORTB
#define MARK433_PIN PINB
#define MARK433_BIT 6
den CUL auf 433Mhz Betrieb umschaltet, sobald er auf Masse gelegt wird (zumindest meldet sich der CUL dann als 433 Mhz Modul)
pi@raspberrypi2 /opt/fhem $ ls -l /dev/serial/by-id/
insgesamt 0
lrwxrwxrwx 1 root root 13 Mär 9 00:22 usb-busware.de_CUL433-if00 -> ../../ttyACM1
Ich melde mich wieder sobald ich Neuigkeiten habe.
Nachtrag zum Bild:
Die Frequenzangabe 433,862Mhz gehört zum gelben Cursor, also zur "zu niedrigen Frequenz"
Gruß
RaspII
Hallo mal wieder,
so... mein "echtes" 868Mhz Modul ist jetzt angekommen....
und ich habe mir einen Arduino pro Mini besorgt... der läuft mit 3.3V (wie das Modul)
... habe den Arduino mit der original FW geflasht (also keine Frequenzverschiebung) und...
es funktioniert wie zuvor....
kurze Tastendrücke auf die Kopp FB kommen einwandfrei an...
bei einen langen Druck auf eine Taste habe ich wieder den Effekt, daß ich mehrere Zeilen bekomme + Checksum Error
Zitat
kr0788109501CC0F0260 <-- kurzer Tastendruck auf Taste 1
kr0788109681CC0F02E3 <-- langer Tastendruck auf Taste 1
E4 Checksum Error
kr07881097F7CC0F0294
kr07881098F7CC0F029B
B2 Checksum Error
@Raspi
konntest du schon etwas rausfinden, warum hier mehrere Zeilen und die Checksum Fehler kommen?
habe einen ESP8266 an den Arduino angeschlossen, mit dem habe ich einen kleinen WebServer erstellt,
somit kann ich über einen Webbrowser mit dem CUL "kommunizieren" (brauche also kein USB...hat der Pro Mini nicht)
....das funktioniert bisher einwandfrei...
Grüße
Stef
Hi,
den Checksumme Fehler kann ich nicht nachstellen (gibt es bei mir nicht)
Wenn wir hier weiterkommen wollen brauch ich ein Systems zum Debuggen.
Kannst Du mir bitte vorab deinen verdrahtungsplan (cc1101 -pro mini, am besten von Hand erstellen) und Deine board.h zusenden?
Gesendet von meinem SM-G900F mit Tapatalk
Bild auf die Schnelle erstellt... (Verdrahtung ist analog zu FHEM SelbstbauCul)
siehe auch http://www.fhemwiki.de/wiki/Selbstbau_CUL (http://www.fhemwiki.de/wiki/Selbstbau_CUL)
Ach ja,
ich hatte Dir noch nicht alle Fragen beantwortet:
Bei einem kurzen Tastendruck wird nur eine Botschaft vom CUL zu FHEM geschickt.
Bei einem langen Tastendruck kommt beim Drücken der Taste die erste Botschaft
kr0788109681CC0F02E3
beim Loslassen der Taste wird vom Sender 2x die "Fertig/Ende" Botschaft gesendet
kr07881097F7CC0F0294
kr07881098F7CC0F029B
Das wäre alles soweit ok, das sieht man am fortlaufenden Blockzähler (96, 97, 98) bei diesen 3 Blöcken.
Am Blockzähler des kurzen Tastendrucks (95) kann man sehen, dass diese Taste unmittelbar zuvor gedrückt wurde.
Nur dass beim langen Tastendruck immer mal wieder ein Checksummenfehler kommt darf nicht sein.
Du musst wissen, dass jeder der angezeigten Blöcke vom Sender tatsächlich 13x gesendet wird (mit identischem Blockzähler).
Da das aber jeweils der selbe Befehl ist, gibt meine culfw dies jeweils nur 1x zu FHEM weiter. D.h. immer nur wenn sich der Blockzähler verändert hat geht eine neue Botschaft zu FHEM. D.h. beim langen Tastendruck geht jeweils eine der 13 Übertragungen schief. Das habe ich bei mir nie gesehen.
Dann nutzt Du ja auch meine neue Software die die "Nullbotschaften" unterdrückt (die es aber wohl immer noch gibt).
Auch das hab ich bei mir noch nie gesehen.
Hattest Du eigentlich schonmal den CSn Pin mit 10kOhm zusätzlich an die 3,3V verbunden?
Ich denke nicht wirklich, dass das was bringt, allerdings ist das der einzige Unterschied den ich in Deiner Verdrahtung im (Vergleich zu meiner) finden kann.
Der einzige weitere Unterschied ist, dass der ProMini einen Atmega 328 als µC hat (soweit ich weiss) und mein ProMicro ein 32U4 wie der original CUL.
(Dein Quarz hat 8 Mhz?, nehme ich an)
Ich könnte Dir noch eine modifizierte kopp_fc.c Datei zusenden, die auch den fehlerhaften Block ausgibt.
Viel wird das aber nicht bringen (man sieht nur wo im Block der Fehler auftritt).
Für eine richtige Fehlersuche müsste ich Deine HW bei mir haben oder zumindest den Fehler auf meiner HW (allerdings ein ProMicro) nachstellen können.
Hallo Raspi,
Du bist aber früh unterwegs...
Vielen Dank für die ausführliche Beschreibung....
Fange die Fehler(?) jetzt in meiner Auswertesoftware ab...
Den 10k Widerstand hatte ich drin, bringt aber nix...kein Unterschied....
Ja der Arduino pro mini hat 8MHz.
Gruß
Stef
Hi,
ich hab jetzt eine kopp-fc.c als "Debug Version gebaut"
Hier erfolgt keine Frequenzkorrektur, müsste also inzwischen für Dich passen.
Ich gebe hier alles an die Konsole aus, was Empfangen wird, und zwar
- Jede empfangene Botschaft mit korrektem Sync Pattern wird weitergereicht
- egal ob Checksummen Fehler oder nicht
Für den Betrieb mit FHEM taugt das ganze nicht, die Aktoren würden dort ca. 13x schalten/toggeln
Zur Fehlersuche könnte es uns ein Stück weiterbringen.
Ich hab es jetzt bei mir geschafft auch die "falschen" "Nullbotschaften" zu empfangen.
Man kann das Hinbekommen wenn z.B. GDO0 und GDO2 vertauscht sind
GDO2 muss in der board.h mit CC1100_xyz verknüpft werden
define CC1100_IN_DDR DDRC // hier muss jeweils der mit GDO2 verbunden Pin spezifiziert sein
define CC1100_IN_PORT PINC
define CC1100_IN_PIN PC6
define CC1100_IN_IN PINC
Compiliere mal Deine Version mit der angehängten kopp.c und schick mir mal eine Log mit Terminalprogramm zu.
Vorher natürlich "krS" eingeben und dann am besten wieder die Tasten drücken wie Du es oben schon mal gemacht hast.
Hallo RaspII,
habe deine Version eingebaut:
so sieht der log aus bei einem kurzen Tastendruck und anschließend einem langen
kr078810A271CC0F0227
kr078810A271CC0F0227
kr078810A271CC0F0227
kr078810A271CC0F0227
kr078810A271CC0F0227
kr078810A271CC0F0227
kr078810A271CC0F0227
kr078810A271CC0F0227
kr078810A381CC0F02D6
kr078810A381CC0F02D6
kr078810A381CC0F02D6
kr078810A381CC0F02D6
kr078810A381CC0F02D6
kr078810A381CC0F02D6
kr078810A381CC0F02D6
67 Checksum Error
kr078810A381CC0F0267
kr078810A4F7CC0F02A7
kr078810A4F7CC0F02A7
kr078810A4F7CC0F02A7
kr078810A4F7CC0F02A7
kr078810A4F7CC0F02A7
kr078810A4F7CC0F02A7
kr078810A4F7CC0F02A7
kr078810A4F7CC0F02A7
kr078810A5F7CC0F02A6
kr078810A5F7CC0F02A6
kr078810A5F7CC0F02A6
kr078810A5F7CC0F02A6
kr078810A5F7CC0F02A6
kr078810A5F7CC0F02A6
kr078810A5F7CC0F02A6
8F Checksum Error
kr078810A5F7CC0F028F
meine board.h sieht so aus:
Zitat
* CC1101 GDO2 Rx Interrupt */
#define CC1100_IN_DDR DDRD
#define CC1100_IN_PORT PIND
#define CC1100_IN_PIN PD2
#define CC1100_IN_IN PIND
nehme ich dein Einstellungen von oben, empfängt das Modul nichts...
ich versteh' das nicht? wann ist es PD2 und wann PC2 respektive PC3 bzw PC2?
und bei dir steht PC6 ????
Gruß
Stef
Hi,
bzgl. GDO2: nein, bei Dir ist alles ok.
Ich hatte bei mir zum Test mal die Pins vertauscht und ich nutze ein Micro CUL mit anderer Pinbelegung. Deine board.h passt zum Schaltplan, alles ok.
Da bei Dir keine Nullbotschaften kommen scheint erst mal alles korrekt zu sein.
Was bei Dir auffällt ist, dass die Botschaften nur 8x kommen (bei meinen Sendern wird immer 13x gesendet).
Folgende Ideen habe ich noch:
a) Dein Sender ist älterer Bauart und hat Bugs (??)
b) Deine Batteri im Sender ist schwach
c) Dein Sender ist defekt (hast Du einen zweiten zum testen?)
d) Die Frequenzeinstellungen für das Kopp Protokoll wurden verändert
-> werden in Deiner fhem.cfg irgend welche Frequenzen angepasst?
-> Verwendest Du noch andere Protokolle parallel.
Was passiert eigentlich wenn Du via FHEM/nanoCUL Daten sendest. Funktioniert das alles problemlos?
Falls ja, könnte ich einfach die Ausgabe des Checksummenfehlers unterdrücken und danach sollte auch bei Deinem System alles funktionieren.
Falls Du einen zweiten CUL/nanoCUL hast, kannst Du auch mal mit diesem Daten senden und prüfen ob Checksummenfehler geworfen werden.
Gruß
RaspII
Hallo RaspII,
Zitat
Was bei Dir auffällt ist, dass die Botschaften nur 8x kommen (bei meinen Sendern wird immer 13x gesendet).
ja das stimmt, habe in den alten Logs nachgeschaut, hatte früher auch 13x, jetzt nur 8x
zu a: Sender ist schon älter, ca. 5-6 Jahre?
zu b: habe die Batterien getauscht, jedoch keine Änderung
zu c: funktioniert mit den Aktoren ganz normal, .... habe auch leider keinen zweiten Sender...
zu d: ich setze noch kein FHEM ein, wie oben erwähnt, habe ich noch eine "HomeAutomation-Eigenentwicklung",die bekommt/sendet die Daten des CUL über USB(COM-Port) bzw. jetzt über ESP8266 (http-Web server)
wenn ich mit dem nanoCUL sende, funktionieren die Aktoren (soweit sie überhaupt noch funktionieren, -> defekte Kondensatoren) einwandfrei, jedoch nicht mit der Reichweite, die ich mit der FB habe.
Unterdrücken des Checksum Fehler wäre gut....
Gruß
Stef
ok,
dann mache ich Dir heute Abend mal eine Version ohne Fehlermeldung bei Checksummenproblemen.
Ich werde das Modul so dann auch offiziell einstellen.
Bzgl. Frequenzeinstellungen:
konfiguriert Du am nanoCUL noch irgend etwas von Hand bzw. oder verlässt Du Dich auf kopp-fc?
(nur die Ausgangsamplitude darf manuell verändert werden, damit kannst Du auch testen ob bzgl. Reichweite noch was zu machen ist)
Gesendet von meinem SM-G900F mit Tapatalk
mit dem neuen 868Mhz Modul, brauch ich eigentlich nichts mehr einzustellen...
da verlass' ich mich auf die "kopp-fc.c", Frequenz lass' ich "original".
Gruß
Stef
Hi,
hab Dir die kopp-fc.c geändert (gibt jetzt keine Checksummenfehler mehr aus, keine Debugausgaben mehr).
Getestet hab ich nicht, allerdings hält sich die Änderung in Grenzen (2 Zeilen auskommentiert).
Gruß
RaspII
Hallo RaspII,
funktioniert jetzt gut...
mir ist jetzt aufgefallen, es kommen die richtigen Tastencodes jeweils einmal
beim langen drücken kommt der richtige Code direkt und erst nach loslassen der Taste kommen
jetzt zwei Zeilen mit Tastencode ...F7...
Zitat
kr0788102501CC0F02D0 <-- kurz gedrückt
kr0788102681CC0F0253 <-- lang dedrückt
kr07881027F7CC0F0224 <-- loslassen der lang gedrückten Taste
kr07881028F7CC0F022B
vielleicht hilft dir das irgendwo.... ich kann in meinem Programm gezielt darauf reagieren, also kein Problem.
Gruß
Stef
Hi
der Sender sendet nach langem Tastendruck den Stopp Block (z.b. beim Dimmen) 2x, d.h. ich Empfange hier 26 Botschaften.
Das ist wohl eine Art Absicherungsmassnahme, damit Rollos auch ganz sicher den Stopp Befehl empfangen.
Ich gebe das genau so weiter.
Ich wollte das auch nicht ändern, macht m.E. schon Sinn.
Gesendet von meinem SM-G900F mit Tapatalk
Ja, verstanden...kann so bleiben,
ist kein Problem für mich, ich kann darauf reagieren...
Vielen Dank
Stef
Hi RaspII,
Ich hab mir eine FHEM testumgebung aufgebaut und dort das Phänomen mit kr00000... Und dem Checksummenfehler jetzt auch. Hast du Deine codeänderungen schon im Sven eingecheckt?
Zusätzlich habe ich immer wieder das komische Verhalten das der nanocul einfach"abstürzt". Dann blinkt die led auf dem Nano nur noch ganz hektisch und nichts geht mehr mit dem Ding, bis man es kurz vom Strom trennt.
Da mir das heute mit zwei nanocul ( beide im Kopp Modus an zwei FHEM Installationen )gleichzeitig passiert ist, vermute ich das ein empfangenes Datenbanken dafür verantwortlich ist. Bisher konnte ich das nicht reproduzieren, werde das mal weiter beobachten. Hast du schonmal was ähnliches gehabt?
Hi,
ich habe ja leider keine nanoCUL.
Bei mir laufen zwei ProMicro Atmega mit CC1101 Modul seit Wochen stabil.
Einer davon mit dem Kopp Protokoll (da passiert aber nicht viel, nur ab und an ein Telegramm)
Ein original CUL läuft ebenfalls mir dem Kopp Protokoll, ebenfalls ohne Problrme.
Ich habe bei mir auch nie Checksummenfehler gesehen,
Nullbotschaften habe ich nur gesehen wenn ich am ProMicro den GDO2 Pin falsch angeschlossen habe.
Gab es bei Dir im Fehlerfall eine bestimmte Aktivität?
Einen Atmega Nano Clone hab ich, vielleicht Bau ich mir mal einen nanoCUL auf
Hi,
Du könntest nochmal etwas testen.
Nutze mal die kopp-fc.c aus meiner Antwort #85
https://forum.fhem.de/index.php/topic,47846.msg430402.html#msg430402 (https://forum.fhem.de/index.php/topic,47846.msg430402.html#msg430402)
Wenn dort ununterbrochen die "Nullbotschaften" kommen, ohne dass eine Taste an der Fernbedienung gedrückt wird liegt das Problem irgendwo auf dem Pfad des GDO2 Pins.
Die Empfangsroutine liest das Fifo des CC1101 aus wenn dieser Pin "aktiv" wird.
Kommen lauter Nullbotschaften ist dieser Pin falsch angeschlossen, falsch konfiguriert oder hat einen kurzschluss etc.
Hi,
probier ich bei nächster Gelegenheit aus.
Zu dem Schnell blinken der LED 13 hab ich auch noch was gefunden, aber nachdem ich das hier (https://forum.fhem.de/index.php?topic=49177.0) gesehen habe bist Du schon auf dem Weg, die Ursache dafür zu verfolgen.
Soweit ich das gelesen habe kommt es dazu, wenn der Watchdog ausgelöst hat, aber der Bootloader nicht mit dem Watchdog umgehen kann.
Siehe : http://www.mikrocontroller.net/topic/390509
Lösung für die Bootschleife, soweit ich das gesehen habe, ist einen andere bootloader zu verwenden.
z.B. Optiboot (https://github.com/Optiboot/optiboot)
(https://andreasrohner.at/posts/Electronics/How-to-make-the-Watchdog-Timer-work-on-an-Arduino-Pro-Mini-by-replacing-the-bootloader/)
Ich werde demnächst mal auf meinem produktiv NanoCul den Bootloader tauschen, mal sehen ob es was bringt.
Bleibt aus meiner Sicht nur noch die Frage, warum der Watchdog überhaupt ausgelöst wird, wenn Du da Hilfe beim Testen brauchst, sag bescheid, Kontaktdaten hast Du ja.
Gruß FD
Wenn ich einen der "Problem namoCULs" auf dem Tisch hätte könnte ich mir selbst ein Bild machen.
(ich zieren mich noch meine verbleibende 866Mhz Briefmarke an einen 5V nanoCUL anzuschließen.
Keiner kann sagen ob night doch Schutzstrukturen etc zerstört werden
Gesendet von meinem SM-G900F mit Tapatalk
Bzgl. Watchdogschleife,
wenn Du Kopp Botschaften empfangen kannst, gibt es bei Dir vermutlich keine Bootschleife.
Ich habe die Bootschleife so verstanden, dass laufend Watchdog Resets ausgeführt werden, das Anwenderprogramm aber nicht ausgeführt wird.
Ich hatte mal in einem Implementierungsstand die culfw sehr lange für das Kopp Protokoll beschäftigt, da hatte dann auch der Watchdog zugeschlagen.
Gesehen hatte mann dann "Teilantworten" vom CUL zu FHEM/Terminal. aber nie eine schnell blinkende LED.
Eine schnell blinkende LED könnte zwar durchaus vom Wathdog kommen, dann würde aber vermutlich kein Protokoll mehr funtionieren.
Ich tippe inzwischen eher auf eine falsche Frequenzapassung etc.
Wenn die led schnell bringt macht der nanocul nichts mehr, auch drücken des Resettasters bringt keine Veränderung. Nur vom Strom trennen ändert das Verhalten. In sofern glaube ich eher an die bootschleife.
Ok
Gesendet von meinem SM-G900F mit Tapatalk
So, die Nullbotschaften und die crc Fehler lagen an einem wackeligen Kabel, der betreffende nanocul ist auf einem breadbord aufgebaut.
Bezüglich des watchdogs und der bootschleife bin ich nun schlauer und kann den Fehler auch reproduzieren.
Vorraussetzung ist eine Arduino nano mit original bootloader.
Der Nano wird nach Anleitung mit einem cc1101 verbunden und die aktuelle culfw geflascht.
Wenn dieser nanoCUL um Kopp_FC Modus auf Empfang steht und viele Botschaften empfangen muss, dann passiert es das der nanoCul abstürzt und in einer Bootschleife stecken bleibt.
Als Lösung habe ich auf den Nano den bootloader von Arduino UNO (optiboot) geflascht und den Fehler versucht erneut zu provozieren. Ohne Erfolg. Nachdem ich den Standart bootloader wieder drauf getan habe, konnte ich den Fehler wieder provozieren.
Ich hoffe das hilft weiter.
Gruß FD
Nö,
das verstehe ich gar nicht.
Könntest Du mit dem Optiboot nochmal überprüfen ob der auch abstürzt, wenn viele Botschaften empfangen werden?
(das musste man über die CUL aktiv Zeit rausbekommen.)
Evt. fängt dieser Bootloader nur die Watchdogresets besser ab.
Kennst Du die Watchdog Periode beim NanoCUL?
Gesendet von meinem SM-G900F mit Tapatalk
Moin,
soweit ich das in der nanoCul.c sehen kann werden 2s für den Watchdog eingestellt, möglich sind Zeiten von 15ms bis 8s.
Das folgende habe ich mir Angelesen:
Bei einem Reset durch den Watchdog wird auch die Watchdogzeit zurückgesetzter nicht der jedoch Watchdog deaktiviert. Das führt dazu, das der Programmcode innerhalb von 16ms (Minimum des Watchdogtimers) den Watchdog deaktivieren oder anderweitig bedienen muss. Dies würde der CulFw Code auch als erstes tun, dazu kommt es jedoch nicht, das der Bootloader nicht in der verbleibenden Zeit abgearbeitet wird und der Watchdog erneut auslöst. Dieser Fehler ist vom standard Bootloader des Arduino Nano bekannt und als Lösung wird Optikboot Vorgeschlagen, da der Bootloader deutlich schneller den eigentlichen Programmcode startet und damit das abschalten des Watchdogs im Programmcode wirken kann, bevor der Watchdog zuschlägt.
Daraufhin habe ich einen nano mit Optikboot über einen anderen nano per ISP-Sketch versehen. (Details wie es geht bei Bedarf.)
Mit dem Optikboot habe ich es bisher nicht hinbekommen den nanoCul zum Absturz zu bringen. Als Gegenprobe habe ich den nanoCUL wieder mit den Original Bootloader versehen und habe ich es wieder hinbekommen den nanoCul zum Absturz zu bringen.
Ich hoffe ich hab nichts vergessen. Mein Produktiver nanoCul (Kopp_FC) läuft jetzt erstmal mit dem alternativen Bootloader und ich hoffe das er stabiler läuft als bisher.
Gruß FD
Hi,
es hat mir einfach keine Ruhe gelassen, warum es überhaupt zu Nullbotschaften kommen konnte.
Ich hatte zwar schon eine Abfanglösung eingebaut, verstanden hatte ich den Wirkmechanismus aber nicht (bis eben).
Ich habe meinen alten Post
https://forum.fhem.de/index.php/topic,47846.msg409228.html#msg409228 (https://forum.fhem.de/index.php/topic,47846.msg409228.html#msg409228)
angepasst. Ein verbessertes kopp-fc kommt bei Gelegenheit.
Bgzl. Watchdog:
Danke für die Info.
Ich habe noch nicht herausgefunden, zu welchem Zeitpunkt der Watchdog in der culfw offiziel zurückgesetzt wird.
Meine Empfangsroutine benötigt eigentlich nicht viel Zeit, deshalb kann ich mir nicht vorstellen, dass hier etwas schief geht.
Wann hattest Du mit dem alten Bootloader die Watchdog Resets gesehen (oder vermutet).
Wenn die Kopp Handsender viel Aktivität erzeugen (nanoCUL empfängt Daten) oder wenn Du über den nanoCUL viel Datenverkehr erzeugst (beim Senden)?
Ich könnte Dir je nach Antwort Testversionen zur Verfügung stellen, die den Watchdog entsprechend ruhig stellen.
Heute habe ich es nur mit häufigem senden provozieren können, Gestern auch beim Empfang. Ich erzeuge beim testen die Daten mit einem anderen nanocul auf einem anderen FHEM. Im Tagesbetrieb kam es auch immer mal wieder vor, wenn man nur zwei oder drei Tasten auf der original FB gedrückt hat. Ich vermute ein Zusammenhang mit dem was hier so in der Nachbarschaft funkt.
Besser fände ich eine Debug version, die Nachrichten produziert, wenn der watchdogs behandelt wurde, dann kann man im log evt nachvollziehen, was passiert ist.
Hi,
das wird schwierig, weil ich mich mit der Standard Watchdog Behandlung nicht auskenne.
Ich bau Dir mal eine Testversion die den Watchdog immer dann ruhigstellt wenn meine kopp-fc "gerufen" wird.
Dann kannst Du zumindest sicher sein, dass die kopp-fc die Ursache für die Watchdog Resets ist.
Sollt das funktionieren muss ich mir überlegen (am besten mit Support von Rudi) wie eine saubere Lösung aussieht,
falls nicht muss Du nach anderen Ursachen suchen, wie z.B.
- Spannungsversorgung ist nicht stabil/bringt zu wenig Strom
Ich fang mal mit dem Watchdog an, evt. bekommst Du schon in ca. 1 Stunde die Testversion.
Lass dir Zeit, ich komme wahrscheinlich erst am we wieder dazu etwas zu testen.
Gruß FD
Zu spät 8)
Anbei die Testversion der kopp-fc.c.
Änderungen:
1.
Bei jedem Aufruf einer Sende oder Empfangstask wird pauschal der Watchdog bedient.
Die Laufzeiten innerhalb der kopp-fc sollten damit nicht mehr zu einem Watchdogreset führen können (das war ja Deine Theorie).
2.
Ich habe für die Empfangsroutine noch einen Debugmode eingebaut
Das Kommando krS startet wie gehabt den "normalen" Empfangsmode u.A. für FHEM
Das Kommando KrS1 gibt alle empfangen Blöcke incl. eventuelle Checksummenfehler aus (letzteres konnte ich mangels Fehler nicht testen)
Das Kommando KrS2 gibt alle empfangen Bytes aus, also auch die "Füll Nullen" am Ende der Botschaft sowie im Fehlerfall jeden Schrott
Dazu muss man eines beachten/wissen:
Der CC1101 ist so konfiguriert, dass er sein Fifo nur füllt sobald ein gültiges Sync Pattern (=AA54 Hex) empfangen wurde.
D.h. typischerweise werden keine Botschaften anderer Prototkolle weitergereicht, es sei denn es wird zufällig ein gültiges Sync Pattern gesendet.
Also nicht wundern, auch im Byte Mode kommen normalerweise nur gültige Kopp Botschaften.
Ich zumindest habe noch nie andere Botschaften gesehen, es sei denn ich hatte Verdrahtungsfehler beim GDO2 Pin.
So, dann wünsch ich Dir viel Spass beim Dauertest
P.S.:
Ich habe bei meinem CCD Modul (läuft im Dauerbetrieb im Kopp-Mode) die Uptime ausgelesen, das Modul läuft seit
7 Tagen, 00:00:34 (Stunden Minuten Sekunden) ohne Reset
Nachtrag 22:09:
die im Beitrag https://forum.fhem.de/index.php/topic,47846.msg434618.html#msg434618 (https://forum.fhem.de/index.php/topic,47846.msg434618.html#msg434618)
angekündigte Verbesserung bzgl. Ausgabe von "Nullbotschaften" habe ich ebenfalls implementiert
So, ich bin zum testen gekommen.
Mit der neuen Kopf_fc.c hab ich es nicht wieder geschafft den nanoCUL zum Absturz zu bringen. Hab vorher extra nochmal mit der Trunk 553 Version getestet um eine Veränderung zu sehen. Also eine gute Änderung.
Ich werde die Versions nachher mal auf meinen Produktiven nanoCUL machen und die Woche beobachten.
Beim testen ist mir noch ein Fehler aufgefallen: Nachdem der nanoCUL ein Reset gemacht hat empfängt FHEM nichts mehr, bis man ein reopen macht. Dabei ist es egal ob man den Resetbutton drückt, oder ob der watchdog den Reset auslöst.
Soweit ich das sehe, bekommt FHEM einen Reset des nanoCUL nicht mit und initialisiert ihn nicht neu. Ich vermute das das ein generelles Thema von FHEM ist. Hab nur noch keine Idee, wo ich das einkippen kann bzw wen ich anschreiben kann.
Soweit erstmal.
Gruß FD
Hallo Feuerdrache,
bzgl.:
ZitatHab vorher extra nochmal mit der Trunk 553 Version getestet
Du hast nicht geschrieben wie Dein Test mit der Trunk Version ausgegangen ist.
Ich nehme mal an, Du hattest damit noch die Probleme?
Ja, mir ist das auch schon aufgefallen, dass nach einem RESET keine Neuinitialisierung passiert, beim abziehen des CULs allerdings schon
(wundert mich etwas).
Generell denke ich aber, dass man das Watchdog/Resetproblem in Griff bekommen sollte.
Ich hatte Rudolf deswegen schonmal angeschrieben, er hatte mir damals auch einige nützliche Tipps gegeben.
Generell denke ich aber man muss defininieren, wie sich die jeweiligen Protokolle bzgl. Watchdog verhalten sollen.
(oder wie viel Zeit man in seinen Routinen benutzen darf)
Was ich im Augenblick beim Kopp Protokoll mache sollte man eigentlich nicht tun (den Watchdog einfach mal bedienen).
Wenn man ausversehen in Endlosschleifen gerät schlägt dann der Watchdog evt. nicht mehr zu und das System bleibt stehen.
Trotz allem macht es schon Sinn wenn FHEM auf Resets reagieren würde.
Dazu müsst man mit dem CUL eine Art "Resetbotschaft" senden und FHEM müsste diese Botschaft auswerten.
Am besten Du startes zu diesem Thema einen neuen Thread.
Hast Du mal nachgeschaut, ob Dein nanoCUL (ATMEGA 328) dieselbe Watchdogzeiten hat wie der Original CUL (32U4) mit 8Mhz?
Was mich noch interessieren würde ist ob Dein System (Kopp) stabil läuft.
Kannst Du mir mal ein Log mit dem Terminal Program zusenden
1x Empfang via Befehl
krS11x Empfang via Befehl
krS2mich interessiert auch was passiert wenn keine Taste an der Fernbedienung gedrückt wird.
Siehst Du dann Botschaften oder nicht?
Gruß
RaspII
Moin,
da ist wohl ein Satz verloren gegangen. Ja mit der trunk Version hab ich den nanoCUL mit häufigem senden zum Absturz bringen können. Nachdem Austausch der Kopp_fc.c nicht mehr. Die angepasste version läuft jetzt auch auf meinem Produktiven FEHM/nanoCUL.
Ich finde es nicht bedenklich, wenn die Kopp Routine den Watchdog beim Aufruf bedient, allerdings habe ich mich in dem Culfw code noch nicht zurechtgefunden. womit arbeitest Du, wenn Du den Code bearbeitest, bzw. wie bekomme ich eine Übersicht welcher Datei ich welche Funktion finde, ohne alle Dateien durchzusehen?
Bezüglich Reset: Fhem bekommt das abziehen und anstecken über den Seriellen port mit, wenn der atmega 328 einen reset macht, bekommt der ftdi seriell zu USB Konverter das evt mit, meldet es aber nicht weiter. Ich sehe das genauso wie Du, es gibt nur die Lösung, das die Culfw beim booten eine Meldung von sich gibt und damit FHEM mitbekommt, das es was tun muss, aber das werde ich mal in einem neuen Thread schreiben.
Das Log mit dem Terminalprogramm muss ich dir noch etwas schuldig bleiben... verschoben, aber nicht vergessen.
Gruß FD
Hi,
für die SW Entwicklung nutze ich WIN-AVR bzw. den mitinstallierten Programmers' Notepad.
Das ist eine gute Entwicklungsumgebung bei der man seine Projekte definieren kann und schnellen Zugriff auf die wesentlichen Daeien hat (legt man im linken Browserfenster fest).
Ich nutze das Tool eigentlich nur als Editor.
Zusätzlich gibt es eine Suche
a) im Dokument
b) über eine Verzeichnisstruktur (siehe Anhang), das Ergebnis steht unten im Ergebnis Fenster.
Dazu musst Du oben in das Folder Symbol neben der Suchleiste anklicken.
Meinen Source Code habe ich auf dem Raspberry Pi und zwar als SVN Clone.
Auf dem Raspi habe ich eine Samba Freigabe eingerichten, damit kann ich komfortabel vom PC aus zugreifen.
Compiliert wird das ganze dann auf dem Raspi.
(Würde theoretisch auch auf dem PC gehen, auf dem Raspi hat man aber schneller die richtige Compiler etc. verfügbar, sollte Rudolf umsteigen (mir war wichtig, das das kompilierte Projekt binärkompatibel zur Übersetzung von Rudolf ist, sofern ich die selben Dateien übersetze).
Moin Rspii, die Testversion von dir verrichtet klaglos ihren Dienst bei mir und macht keine Mucken. Hab trotz Standard Bootloader keine Notschreien mehr gehabt.
Gesendet mit einer zu kleinen Tastatur
Hi,
Ok, dann mache ich die neue FW bei Gelegenheit mal "offiziell".
Aktuelle kopp-fc ist in SVN eingestellt. Sobald Rudolf die FW wieder baut gibt es dann die nächste offizielle Version.
Zitat von: RaspII am 27 April 2016, 17:01:36
Hi,
Ok, dann mache ich die neue FW bei Gelegenheit mal "offiziell".
Aktuelle kopp-fc ist in SVN eingestellt. Sobald Rudolf die FW wieder baut gibt es dann die nächste offizielle Version.
Hi,
finde nur das Zitat, keinen weiteren Kommentar?
Trotzdem mal den Status:
Es könnte beim Bauen der neuen CUL FW zum Überlauf des Flashes kommen, da mein kopp_fc Modul jetzt mehr Speicher braucht wie verfügbar.
Da sich das Kopp Modul nur exclusive nutzen lässt, werde ich vermutlich eine eigene Kopp culfw Variante bauen.
Ich ahbe aber gerade keine Zeit, d.h. komme vermutlich erst im Herbst dazu.
Gruß
RaspII
Hallo RaspII
Ich habe mal einen Nano mit 868MHz aufgebaut.
Der Kopp Rolladenschalter 8080.02 wird erkannt allerdings geht nur eine Richtung.
define Rolladen KOPP_FC F7 9EAA 03 00
Also stop, down, bottom geht aber nix mit rauf.
CUL_A_RAWMSG kr079EAAE8F7CC0F0346
Definitionsfehler oder was könnte das sein?
Gruß Dieter
Hallo Dieter,
hast Du schon die Kopp Seite in der FHEM-Wiki gefunden?
Dort sind einige Informationen die Dir evt. helfen.
http://www.fhemwiki.de/w/index.php?title=Kopp_Allgemein&redirect=no (http://www.fhemwiki.de/w/index.php?title=Kopp_Allgemein&redirect=no)
Dein Problem ist vermutlich, dass Du den Tastencode 1 mit "F7" festgelegt hast.
"F7" ist kein gültiger Tastencode sondern wird vom Sender nach dem Loslassen einer beliebigen Taste (langer Tastendruck) gesendet, dieses Kommando kennen alle Empfänger/Aktuatoren ohne das man es anlernen muss. Auch mein FHEM Modul generiert diesen Code automatisch beim Drücken der "Stop" Taste (siehe Wiki).
Ansonsten hast Du alles richtig gemacht, wenn Dein Rolladen schon runter fährt ist der Rest kein Hexenwerk, d.h. Du musst nur noch den korrekten Tastencode1 finden und definieren.
Für Dich müsste die Definition vermutlich wie folgt aussehen, Du findest das Ergebnis dann im Raum "Test"
define TasteUp KOPP_FC 10 9EAA 03 00
attr TasteUp IODev CUL_0
attr TasteUp devStateIcon up:fts_shutter_up down:fts_shutter_down stop:fts_shutter_updown top:fts_shutter_10 bottom:fts_shutter_90
attr TasteUp eventMap up:up down:down stop:stop top:top bottom:bottom
attr TasteUp group Rolladen
attr TasteUp model Blind_8080_02
attr TasteUp room Test
attr TasteUp webCmd top:up:stop:down:bottom
In der Wiki findest Du das Beispiel unter:
Rolladen (8080.02), über zwei Taster gesteuert (top, up, stop, down, bottom)
Als Tastencode1 (up) ist "10" definiert, als Tastencode2 ist wie bei Dir die "00" festgelegt
Diese Codes senden die meisten Kopp Wandschalter, soll FHEM den selben Code senden wie Dein Wandschalter musst Du nachschauen (im Log File) was Dein Wandschalter sendet wenn Du die "Up" und "Down" Tasten jeweils kurz drückst.
So, dann hoffe ich Du hast Erfolg mit der Info
Gruß
RaspII
Hallo RaspII
Danke - genau das war es!
Z.Z. laufen sie nun nur leider "Verkehrtherum" also runter statt rauf.
Das müsste doch mit Vertauschen des Tastencodes 1 mit 2 erledigt sein.
Jetzt noch ein paar Kettenbefehle: alles rauf oder runter oder nach Zeit usw...
Prima - Sache läuft endlich.
Gruß Dieter
Ja, tauschen der Tastencodes sollte reichen.
Freut mich das es klappt.
Viel Spaß mit dem Modul
Gruß
RaspII
Gesendet von meinem SM-G900F mit Tapatalk
Hallo es gibt leider noch ein kleines Problem:
Doppeltaster: KR073123A630 (linke Taste rauf oder runter) und dann
KR073123A820 (rechte Taste rauf oder runter).
Also 2 Rollladen Empfänger und ein Doppeltaster.
Wie soll ich die definieren?
Übrigens Bestätigung: Tastencodes Tauschen und die Dinger laufen andersherum.
Gruß Dieter
Zitat von: dieter114 am 12 Dezember 2016, 18:31:38
Hallo es gibt leider noch ein kleines Problem:
Doppeltaster: KR073123A630 (linke Taste rauf oder runter) und dann
KR073123A820 (rechte Taste rauf oder runter).
Also 2 Rollladen Empfänger und ein Doppeltaster.
Wie soll ich die definieren?
Übrigens Bestätigung: Tastencodes Tauschen und die Dinger laufen andersherum.
Gruß Dieter
Hi,
Habs noch nicht verstanden.
Was ist das eigentliche Problem ?
Gesendet von meinem SM-G900F mit Tapatalk
Ist das Problem, das Du nur je ein Taster (also ein Kontakt) pro Rolladen hast?
Gesendet von meinem SM-G900F mit Tapatalk
Nein, es gibt doppelte Taster.
Also 2 Wippen (rechts und links) für je ein Fenster rauf und runter.
Das sind zwei Taster in einem Gehäuse.
http://www.elv.de/kopp-free-control-funk-wandschalter-standard-2fach-creme-weiss.html
plus dazu zwei mal 8080.02 Rolladenschalter.
Dann muss es aber 4 verschiedene Codes geben.
Drück die Tasten mal nacheinander (nur kurz) und schaue im FHEM Logfile nach
Gesendet von meinem SM-G900F mit Tapatalk
Hab ich gemacht:
Taste Links Rauf: Kr 07 A4 08 18 30 CC 0F 03 E9
Taste Links Runter: Kr 07 A4 08 1B 20 CC 0F 03 FA
Taste Rechts Rauf: Kr 07 A4 08 1D 10 CC 0F 03 CC
Taste Rechts Runter: Kr 07 A4 08 21 00 CC 0F 03 E0
Das passt alles irgendwie nicht mit deiner Definition zusammen, oder ich verstehe es nicht richtig.
Hast du ggf. eine Lösung dafür?
Gruß Wolfdieter
HiHo,
da sind deine 4 Tastencodes:
Links Rauf: 30
Links Runter: 20
Rechts Rauf: 10
Rechts Runter: 00
Also die definition deines linken Schalters müsse ungefähr so aussehen:
define LinkerSchalter KOPP_FC 00 A408 03 10
attr LinkerSchalter IODev CUL_0
attr LinkerSchalter devStateIcon up:fts_shutter_up down:fts_shutter_down stop:fts_shutter_updown top:fts_shutter_10 bottom:fts_shutter_90
attr LinkerSchalter eventMap up:up down:down stop:stop top:top bottom:bottom
attr LinkerSchalter group Rolladen
attr LinkerSchalter model Blind_8080_02
attr LinkerSchalter room Test
attr LinkerSchalter webCmd top:up:stop:down:bottom
und der des rechten
define RechterSchalter KOPP_FC 20 A408 03 30
attr RechterSchalter IODev CUL_0
attr RechterSchalter devStateIcon up:fts_shutter_up down:fts_shutter_down stop:fts_shutter_updown top:fts_shutter_10 bottom:fts_shutter_90
attr RechterSchalter eventMap up:up down:down stop:stop top:top bottom:bottom
attr RechterSchalter group Rolladen
attr RechterSchalter model Blind_8080_02
attr RechterSchalter room Test
attr RechterSchalter webCmd top:up:stop:down:bottom
Aus meiner Erfahrung mit der Kopp Rolladensteuerung mit FHEM, kann ich dir noch dan Tipp mitgeben, das Du zwischen hoch und runt befehlen stopp drücken solltest, auch wenn der Rolladen nicht mehr fährt. FHEM weiß nicht in welchem zustand der Rolladen ist und nimmt daher an, das er noch runterfährt nachdem runter gedrückt wurde, auch wenn der Rolladen schon längst unten ist.
Gruß FD
Ja und neín:
Ein Rolladen fährt gelegentlich aber bei beiden geht kein Stopp Befehl.
Ich habe viele andere Rolläden mit 1 Taster dazu.
Die laufen alle Einwandfrei.
Es muss noch was Anderes sein.
Gruß Wolfdieter
Hi,
mir ist aufgefallen, dass im Beispiel oben
KOPP_FC 00 A408 03 10
zwischen A408 und 03 ein Leerzeichen zu viel ist.
Bin mir nicht sicher was die Firmware daraus macht.
Richtig wäre
KOPP_FC 00 A408 03 10
Gruß
RaspII
Hmm,
Ich kenne nur kopp Rollläden mit zwei Tasten Steuerung, also eine für rauf und eine für runter.
Sind die eintasten Rollladen auch von kopp?
Sind die beiden Rolläden evt die am weitesten entfernten von deinem FHEM Sender?
Was für Hardware verwendest du um die Signale zu senden?
Gruß FD
Also:
Ich verwende einen Arduino Nano mit 862MHz (echtes 862er Modul) als CUL.
Die Rolläden sind einwandfrei zu erreichen, der Sender hat schon ordentliche Leistung.
Das Problem sind die Doppeltasten-Sender, also zweimal eine Wippe nebeneinander:
http://www.elv.de/kopp-free-control-funk-wandschalter-standard-2fach-creme-weiss.html
Bitte die Bilder mal ansehen, damit wir nicht aneinander vorbeireden.
Also zweimal 2-Tasten Steuerung in einem Gehäuse für 2 Empfänger und 2 Rollläden.
@RaspII: Die Leerzeichen sind natürlich nicht in der Definition drin, das würde wohl nicht laufen.
Hier die empfangenen Daten:
Taste Links Rauf: Kr 07 A4 08 18 30 CC 0F 03 E9
Taste Links Runter: Kr 07 A4 08 1B 20 CC 0F 03 FA
Taste Rechts Rauf: Kr 07 A4 08 1D 10 CC 0F 03 CC
Taste Rechts Runter: Kr 07 A4 08 21 00 CC 0F 03 E0
Damit sollte die Definition eigentlich sein:
define LinkerSchalter KOPP_FC 00 A408 03 30 und
define RechterSchalter KOPP_FC 20 A408 03 10
geht nur leider nicht.
4 andere Rolläden mit Einzeltastenbedienung laufen einwandfrei mit meiner Hardware.
Gruß Wolfdieter
Kannst Du bitte mal das Bild von Deinem 868MHz Modul sowie Deinen Anschluss Plan posten?
Gesendet von meinem SM-G900F mit Tapatalk
Gern, muss aber erst nen Foto machen.
Was soll daran falsch sein, wenn 4 andere Rolladenantriebe damit einwandfrei gesteuert werden können?
Wenn alle Rolladenantriebe über Kopp Aktuatore gesteuert werden und funktionieren hilft das in der Tat nichts
Gesendet von meinem SM-G900F mit Tapatalk
ZitatHier die empfangenen Daten:
Taste Links Rauf: Kr 07 A4 08 18 30 CC 0F 03 E9
Taste Links Runter: Kr 07 A4 08 1B 20 CC 0F 03 FA
Taste Rechts Rauf: Kr 07 A4 08 1D 10 CC 0F 03 CC
Taste Rechts Runter: Kr 07 A4 08 21 00 CC 0F 03 E0
Damit sollte die Definition eigentlich sein:
define LinkerSchalter KOPP_FC 00 A408 03 30 und
define RechterSchalter KOPP_FC 20 A408 03 10
geht nur leider nicht.
Hm,
wenn ich mir das nochmal anschaue gibt es doch einen Fehler.
Deine Definition
define LinkerSchalter KOPP_FC 00 A408 03 30definiert die Funktionen Rechts
runter und
Links rauf.
Richtig wäre für Links rauf / runter define LinkerSchalter KOPP_FC 20 A408 03 30 oder evt. auch andersrum (bin da nicht 100% sicher)
define LinkerSchalter KOPP_FC 30 A408 03 20Richtig wäre für Rechts rauf / runter define LinkerSchalter KOPP_FC 00 A408 03 10oder evt. auch andersrum (bin da nicht 100% sicher)
define LinkerSchalter KOPP_FC 10 A408 03 00
Richtig, so ist es auch.
Hatte mich vertippt - Entschuldige.
00.....10 und 20.......30 so ist die Definition.
Geht trotzdem nicht.
Ich glaube es muss mehr als nur die ID A408 und die Codes 00 10 20 30 definiert werden.
Bei diesen Doppelwippen ist noch mehr zu beachten.
Was ist mit den Zahlen hinter der ID A408
also z.B. die 18 vor dem KEYCODE2 30
Die Zahl (beim Empfang) direkt nach den Keycode1 (A408) ist der Blockzähler.
Er wird von der Fernbedienung nach jedem Tastendruck erhöht.
Hintergrund:
Der Aktuator erkennt am Blockzähler, dass ein neuer Tastendruck erfolgt ist (z.b. wenn die selbe Taste mehrmals hintereinander gedrückt wurde).
Die Kopp Firmware im CUL Stick erhöht diesen Zähler automatisch nach jedem Kommando (vom CUxD oder von FHEM).
Jeder Sendeauftrag wird 13x mit identischem Blockzähler gesendet
(irgendwie muss der Empfänger ja unterscheiden können, ob ein neuer Tastendruck erfolgt ist oder nur eine Blockwiederholung erfolgt ist).
Das hilft Dir jetzt aber nicht weiter.
Irgendwie bin ich mit Deinem Problem jetzt etwas ratlos.
Das einzige was mir noch dazu einfällt wäre, dass nicht beide Tasten einer Wippe (hoch/runter) in einem Anlernzyklus am Kopp Empfänger angelernt wurden, sondern nur eine Taste.
Kannst Du nachvollhiehen, dass die Rolläden mit den Tastendrücken der entsprechenden Wandsender immer funktionieren (also Taste hoch -> hoch und Taste runter -> runter?), via CUL Stick aber nicht?
(mit in etwa dem selben Abstand zu den Empfängern/Aktuatoren)?
Ich habe Dich schon richtig verstanden, alle anderen Rolladen lassen sich über den Nano CUL und Kopp Protokoll steuern (auch per Wippe oder nur per Taste)?
Zitat von: RaspII am 20 Dezember 2016, 00:14:35
Kannst Du nachvollhiehen, dass die Rolläden mit den Tastendrücken der entsprechenden Wandsender immer funktionieren (also Taste hoch -> hoch und Taste runter -> runter?), via CUL Stick aber nicht?
(mit in etwa dem selben Abstand zu den Empfängern/Aktuatoren)?
Ich habe Dich schon richtig verstanden, alle anderen Rolladen lassen sich über den Nano CUL und Kopp Protokoll steuern (auch per Wippe oder nur per Taste)?
Das hast du richtig verstanden!
Alle (einfach)Rollläden lassen sich per Wippe(n) oder über CUL einwandfrei steuern.
Meine 9 Antriebe haben 9 Kopp Schaltmodule und 3 Doppelwippenschalter sowie 4 Einfachwippenschalter.
Für Rollläden gibt es nur Wippen mit Rauf- Runter Wippe. Irgendwelche Taster habe ich nicht und sind mir auch unbekannt.
Der Anlernvorgang ist wie immer: Modul in Prog-Modus; Taste Rauf; Prog; Taste Runter; Prog - Fertig.
D.H. die Doppelwippentaster werden in zwei Zyklen für zwei Schaltmodule angelernt,
sie verhalten sich also wie zwei einzelne Einfachwippenschalter.
Hallo nochmal,
auch wenn meine Fragerei nervt:
ZitatAlle (einfach)Rollläden lassen sich per Wippe(n) oder über CUL einwandfrei steuern.
bedeutet das, mit einem Standard CUL funktioniert die selbe Konfiguration problemlos, mit dem NanoCUL nicht?
Wenn ich mit obiger Feststellung richtig liege gibt es nicht viele Möglichkeiten, hier mal meine Vermutungen:
- nicht alle notwendigen Singnalleitungen sind vom NanoCUL zum CC1101 verbunden
- Die Pegelanpassung (3V3 auf 5V) verändert das Timing der Signale
- Du hast ein "schlechtes" CC1101 Modul erwischt, ich hatte selbst schon welche die nicht auf der richtigen Frequenz gesendet hatten
zu 1.:
am besten die Schaltung posten oder hier im Forum referenzieren
Ich habe unter folgendem Link
https://forum.fhem.de/index.php/topic,47846.msg420229.html#msg420229 (https://forum.fhem.de/index.php/topic,47846.msg420229.html#msg420229)
einen Schaltplan mit allen notwendigen Signalen gezeichnet. Ich habe das zwar für den ProMicro gemacht, die Signale am CC1101 Modul sind aber die selben
(
alle Signale müssen verdrahted und in der FW entsprechend konfiguriert sein).
zu 2.:
hier hilft nur nachmessen (hast Du einen Oszi?)
zu 3.:
am besten doch mal ein Bild oder einen Link vom CC1101 Modul posten, dann kann ich zumindest sagen ob ich Erfahrungen mit diesem Modul habe
Weiter vorne im Forum gibt es Tipps wie man die Frequenz per "Software Defined Radio" nachmessen kann (das ist echt ein geiles Tool, Kosten für DVB-T Empfänger 15€)
https://forum.fhem.de/index.php/topic,47846.msg414134.html#msg414134 (https://forum.fhem.de/index.php/topic,47846.msg414134.html#msg414134)
Ich habe leider keinen NanoCUL am Laufen (nur ProMicro, der wird mit 3V3 betrieben), mit dem Nano CUL hatten Anwender hier im Thread schon kuriose Effekte, die ich mit dem Original CUL und ProMicro nicht nachvollziehen konnte. Ich hatte damals meine Firmware robuster gemacht, erklären konnte ich die Unterschiede aber nicht.
Nachlesen kannst Du das hier:
https://forum.fhem.de/index.php/topic,47846.msg415367.html#msg415367 (https://forum.fhem.de/index.php/topic,47846.msg415367.html#msg415367)
So, ich hoffe mal dass da etwas neues für Dich dabei war.
Ansonsten bin ich mit meinem Latein am Ende, da würde nur noch selbst nachmessen helfen (Du bist nicht zufällig im Stuttgarter Raum?)
Zitat von: dieter114 am 21 Dezember 2016, 17:43:09
Das hast du richtig verstanden!
Alle (einfach)Rollläden lassen sich per Wippe(n) oder über CUL einwandfrei steuern.
Meine 9 Antriebe haben 9 Kopp Schaltmodule und 3 Doppelwippenschalter sowie 4 Einfachwippenschalter.
Für Rollläden gibt es nur Wippen mit Rauf- Runter Wippe. Irgendwelche Taster habe ich nicht und sind mir auch unbekannt.
Der Anlernvorgang ist wie immer: Modul in Prog-Modus; Taste Rauf; Prog; Taste Runter; Prog - Fertig.
D.H. die Doppelwippentaster werden in zwei Zyklen für zwei Schaltmodule angelernt,
sie verhalten sich also wie zwei einzelne Einfachwippenschalter.
Hallo Entschuldige die späte Antwort,
aber Weihnachten ist auch mal Auszeit.....
Zur Klarstellung als Ergänzung zum Zitat oben:
Ich habe nur einen Nano-CUL mit angelötetem echtem 868 Modul.
Mit diesem Modul kann ich alle Rollläden schalten, die über einfache Wippen (ein Wippschalter -> ein Rolladen) gesteuert werden.
Mit dem selben Modul wurden die ob.g. Doppelwippen wie beschrieben angelernt.
Im Log werden die über die Wippe gegebenen Befehle richtig angezeigt
nur ich kann die Befehle nicht mit fhem auslösen, was bei den "Einfachwippen" problemlos geht.
Es muss irgendwas mit den Codes 00 10 20 30 für rauf und runter zu tun haben.
Diese Doppelwippen senden wohl noch irgendwas Anderes mit aus.
Kann man irgendwie den vollen gesendeten Datensatz auslesen?
Gruß Wolfdieter
Zitat von: dieter114 am 17 Januar 2017, 22:53:23
Hallo Entschuldige die späte Antwort,
aber Weihnachten ist auch mal Auszeit.....
Zur Klarstellung als Ergänzung zum Zitat oben:
Ich habe nur einen Nano-CUL mit angelötetem echtem 868 Modul.
Mit diesem Modul kann ich alle Rollläden schalten, die über einfache Wippen (ein Wippschalter -> ein Rolladen) gesteuert werden.
Mit dem selben Modul wurden die ob.g. Doppelwippen wie beschrieben angelernt.
Im Log werden die über die Wippe gegebenen Befehle richtig angezeigt
nur ich kann die Befehle nicht mit fhem auslösen, was bei den "Einfachwippen" problemlos geht.
Es muss irgendwas mit den Codes 00 10 20 30 für rauf und runter zu tun haben.
Diese Doppelwippen senden wohl noch irgendwas Anderes mit aus.
Kann man irgendwie den vollen gesendeten Datensatz auslesen?
Gruß Wolfdieter
Hallo,
Du hast das im Beitrag #129 schon gemacht.
Dort siehst Du was dier Wandschalter sendet.
(Wenn noch keine passende Definition in der FHEM.cfg steht, sind im Logfile die Rohdaten zu sehen).
Eigentlich sollte alles stimmen, ich kann mir noch eine unvollständige Verdrahtung zum CC1101 vorstellen.
Gesendet von meinem Nexus 7 mit Tapatalk
Das kann eigentlich nicht sein:
Wenn ein Hardwarefehler vorliegen sollte, würde genau dies Modul nicht die Rollläden
mit "Einfachschalter" einwandfrei schalten.
Also nochmal:
Das Modul erkennt einfach Wippen und schaltet den zugehörigen Rollladen.
Wenn zwei Rollläden mit einer Doppelwippe geschaltet werden geht es nicht.
Also kann es doch nur an der Erkennung und daraus resultierendem Code-Sendefehler liegen - oder?
In Post 129 hat Feuerdrache die Tastencodes mit 00 10 20 30 angegeben.
Die habe ich genau so umgesetzt.
Ein Rollladen fährt mit 00 rauf und mit 10 runter,
der andere mit 20 rauf und mit 30 runter oder so.
Das wird auch im Log angezeigt wenn ich die Taster betätige.
Nur ein Programmbefehl richtet nichts aus.
Ich behaupte an diesen 00 10 20 30 ist was falsch.
Die Doppeltaster senden wohl noch irgendwas Anderes mit aus.
Gruß Wolfdieter
Dann machen wir irgendwo einen Denkfehler.
Das die Wippen noch etwas anderes senden wäre für mich völlig neu.
Z.B. Dein Post 134: handelt es sich bei diesen empfangenen Daten um die Doppeltwippen? Falls ja, sind die 00 10 20 30 richtig, da kommt nicht anderes.
Ich denke denke wir benötigen eine gemeinsame Debugsession. Ich habe frühestens am Samstag oder Sonntag für ca. eine Stunde Zeit.
Bis dahin überlege ich mir ob du evt. selbst noch weitere Tests machen kannst.
Bzgl. Verdrahtung:
Es wäre nicht das erste Mal, dass eine minimal falsch verdrahtet Schaltung bei einigen Anwendungen problemlos funktioniert.
Was mich etwas stutzig macht:
Derartige Probleme gab es in der Vergangenheit mit in Verbindung mit dem NanoCUL (z.B. hatte ein Anwender immer mal wieder Checksummenfehler gesehen, die nur in Verbindung mit dem NanoCUL auftraten.
Vielleicht haber wir jetzt die Chance und finden ein systematisches Problem (z.B. bei der Anpassung von 5V auf 3V, die benötigt man beim CUL oder ProMicroCUL nicht.
Ich besitze keinen NanoCUL, Deine Schaltung schicken schadet zumindest nicht.
Gesendet von meinem Nexus 7 mit Tapatalk
Gute Idee
ich überleg mir auch mal was.
Notfalls packe ich meinen Nano-Cul in ne Tüte und sende dir das Teil zu.
Eine Doppelwippe kann ich dir nicht zusenden - das würde mächtig Ärger mit dem "Haushaltsvorstand" geben.
Gruß Wolfdieter
Doppelwippen habe ich, die Frage ist ob es dieselbe ist.
Ich bin heute evt. Früher zuhause wie geplant und könnte evt ab 17:00 bis 19:00 Skype falls das bei Dir passt
Gesendet von meinem SM-G900F mit Tapatalk
Bin jetzt zuhause.
Hab mir nochmal angeschaut was Du ohne mich testen könntest.
Wenn Du den NANOCul per Terminalfenster betreibst (dann sollte FHEM ausgeschaltet sein), kannst Du im Terminal folgenden Befehl eingeben:
krS2
Die CUL Firmware läuft dann in einer Art Debugmode und gibt alle möglichen Informationen preis.
Danach bitte jede Taste des Schalters 1x kurz drücken, dazwischen immer ca. 2sec warten
Dazwischen bitte keine anderen Sender etc. bedienen.
Das Ergebnis im Monitor Fenster bitte als Text kopieren und mal hier anhängen.
So Leute, ich habe die Probleme in den Griff bekommen. :) :)
Für Alle die es interessiert hier kurz die Zusammenfassung diverser Testreihen und Mails zwischen RaspII und mir:
Die grünen "Billig-Briefmarken" Typ RF1101SE V3.1 vom Chinamann habe recht ungenaue Quarzoszillatoren.
Soll heißen die Frequenz, die vom Arduino aus eingestellt wird, stimmt einfach nicht.
Meine Geräte senden gut 500KHz zu hoch, und das ist für die Empfänger trotz sehr breitbandiger Aussendung zu viel Abweichung.
Da der Sketch für den Arduino so abgewandelt wurde das über fhem keine Änderung der Frequenz mehr zu machen ist,
habe ich die Frequenz eben im Sketch selbst geändert. Sofort liefen alle meine Rollläden ohne Probleme.
Weiterhin habe ich festgestellt das die Taster an den Wänden sehr unterschiedliche Sendefeldstärken aufweisen.
So ist es gut möglich ein Exemplar mit doppelt so großer Feldstärke wie sein Nachbar daneben zu haben.
Dies hat dazu geführt, das einer nicht erkannt wurde. Es macht also durchaus Sinn den Taster ggf. in die Nähe des CUL`s zu bringen.
Von RaspII habe ich erfahren, das er über eine Einstellmöglichkeit der Frequenz von fhem aus nachdenkt und die SW ggf dafür noch anpasst.
Von hier aus noch einen Dank an RaspII und alle anderen die mir geholfen haben.
Schöne Grüße aus Ilsede
Wolfdieter
Zitat von: stoffel am 13 Februar 2016, 19:13:54
Hallo Raspi,
Feuerdrache hat es schon geschrieben, habe mir den DV-T stick geholt (15€)....
War etwas "tricky" den zum Laufen zu bringen...
Bei mir kommen nach wie vor die 2x13 Pakete jeweils immer mit den "0000000000" dazwischen...
Bin aktuell nicht Zuhause, kann also nicht nachschauen...
Gruss
Stef
Hallo Stoffel,
ich muss mich nach dieser langen Zeit doch nochmal melden.
Ich habe mir jetzt selbst einen NanoCUL aufgebaut, alles klappt völlig problemlos.
Allerdings habe ich die Spannungsteiler für die Pegelwandlung von 5V auf 3V3 mit 1k & 470Ohm Widerständen aufgebaut (anstelle von 10k und 4k7).
Es gab immer wieder Hinweise, dass die hochohmigen Spannungsteilern zu Fehlern (z.B. Lesefehlern) führen können, z.B. hier:
https://forum.fhem.de/index.php/topic,43467.msg587477.html#msg587477 (https://forum.fhem.de/index.php/topic,43467.msg587477.html#msg587477)
oder hier:
https://wiki.fhem.de/wiki/Selbstbau_CUL#Schaltplan
(https://wiki.fhem.de/wiki/Selbstbau_CUL#Schaltplan)
Da eigentlich noch immer nicht geklärt ist warum sich Dein NanoCUL so unterschiedlich zu meinen ProMicroCULs verhalten haben, würde mich interessieren welche Spannungsteiler bei Dir verbaut sind.
Dein eigentliches Problem haben wir ja dadurch gelöst, das ich "schlecht empfangene" Botschaften ignoriere, trotzdem lässt mir die Sache keine Ruhe (die Spannungsteiler könnten eine Erklärung sein)
Hallo RaspII
auch meine Rollläden laufen nun so leidlich fehlerfrei.
Allerdings habe ich Reichweitenprobleme mit der kleinen Antenne und einem Ytong-Haus.
Das ist eigentlich ein großer Faradayscher Käfig wegen der Metallteile im Porenbeton.
Kann das auch evt. mit den Spannungsteilern zusammenhängen?
Bei mir sind keine verbaut, und die Dinger laufen eigentlich auch so.
Als Ergänzung zum Wiki hier ein Vorschlag für die Steuerung "aller" Rollläden auf einmal:
# Alle Rolläden per Befehl steuern
define Alle_Rollos structure KOPP_FC Rolladen_HWR Rolladen_Bad Rolladen_Annika Rolladen_Kristina_Tuer Rolladen_Kristina_Fenster Rolladen_Schlafzimmer Rolladen_Wohnzimmer_Alle
attr Alle_Rollos devStateIcon up:fts_shutter_up down:fts_shutter_down stop:fts_shutter_updown top:fts_shutter_10 bottom:fts_shutter_90
attr Alle_Rollos eventMap up:up down:down stop:stop top:top bottom:bottom
attr Alle_Rollos group Rolladen
attr Alle_Rollos room Rolladen
attr Alle_Rollos webCmd top:up:stop:down:bottom
#
Der Befehl structure geht dafür problemlos.
Weiterhin habe ich einmal den Befehl ROLLO ausprobiert, geht auch ohne Probleme.
Es wird lediglich per Set Befehl ein Rolladen "Zeitgesteuert" um bestimmte Stellhöhen zu erreichen.
# Rollo Befehl um bestimmte Höhen zu erreichen
define R_RolloHWR ROLLO
attr R_RolloHWR alias RolloHWR
attr R_RolloHWR autoStop 0
attr R_RolloHWR commandDown set Rolladen_HWR down
attr R_RolloHWR commandStopDown set Rolladen_HWR stop
attr R_RolloHWR commandStopUp set Rolladen_HWR stop
attr R_RolloHWR commandUp set Rolladen_HWR up
attr R_RolloHWR devStateIcon open:fts_shutter_10:closed closed:fts_shutter_100:open half:fts_shutter_50:closed drive-up:fts_shutter_up@red:stop drive-down:fts_shutter_down@red:stop position-100:fts_shutter_100:open position-90:fts_shutter_80:closed position-80:fts_shutter_80:closed position-70:fts_shutter_70:closed position-60:fts_shutter_60:closed position-50:fts_shutter_50:closed position-40:fts_shutter_40:open position-30:fts_shutter_30:open position-20:fts_shutter_20:open position-10:fts_shutter_10:open position-0:fts_shutter_10:closed
attr R_RolloHWR excessBottom 2
attr R_RolloHWR excessTop 4
attr R_RolloHWR resetTime 0
attr R_RolloHWR room Rolladen
attr R_RolloHWR secondsDown 30
attr R_RolloHWR secondsUp 30
attr R_RolloHWR switchTime 1
attr R_RolloHWR type normal
attr R_RolloHWR webCmd open:closed:half:stop:position
#
Das (inoffizielle) Modul muss erst eingebunden werden:
update all https://raw.githubusercontent.com/RettungsTim/fhem-rollo/master/controls_fhemrollo.txt
Und hier der Thread dazu
https://forum.fhem.de/index.php/topic,47202.0.html
Gruß Wolfdieter
Hallo Zusammen,
ich hab mir einen nanoCUL gemäß WIKI angelegt. jedoch komm ich dann nicht weiter.
kann mir jemand sagen wie ich
Kopp Sender auswerten
Um erste FHEM Erfahrungen mit Kopp Sender und Aktuatoren zu machen ist es sinnvoll innerhalb von FHEM ein Device anzulegen, das die selben Kommando versendet wie ein vorhandener Kopp Sender. Nachdem z.B. einem CUL USB Stick das Kopp Protokoll zugeswiesen wurde können in der FHEM Oberfläche über den Link "CUL_0" (mein Beispiel) vom Kopp Sender übermittelte Telegramme ausgewertet werden. Drückt man danach eine Taste des Senders und aktualisiert das Browser Fensert, ist dort ein Eintrag ähnlich:
RAWMSG kr07C2AD1A30CC0F0328
zu sehen. Dabei handelt es sich um die vom Sender gesendeten Roh-Daten, die wir teilweise innerhalb von FHEM wiederverwenden.
das hier umsetzen muss da passiert bei mir nichts.
ich habe RAWMSG garnicht.
Hi,
Kannst Du mal posten was Du konfiguriert hast?
Hat der NANOCUL schon mit einem anderen Protokoll funktionier?
Gruß
RaspII
Hi RaspII
bin etwas weiter bekomme nun Raw Daten
List KoppCUL
Internals:
CMDS ABCEeFfGhiKklMmRTtUVWXxYZz
Clients :KOPP_FC:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9M9DV3R-if00-port0@38400 1234
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9M9DV3R-if00-port0@38400
FD 22
FHTID 1234
KoppCUL_MSGCNT 41
KoppCUL_TIME 2017-05-27 04:25:04
NAME KoppCUL
NR 49
PARTIAL
RAWMSG kr07D7C13920CC0F0465
STATE Initialized
TYPE CUL
VERSION V 1.67 nanoCUL868
initString krS
Matchlist:
1:Kopp_FC ^kr..................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
Readings:
2017-05-25 14:02:04 ccconf freq:868.300MHz bWidth:162KHz rAmpl:42dB sens:8dB
2017-05-25 14:54:22 cmds A B C E e F f G h i K k l M m R T t U V W X x Y Z z
2017-05-25 14:02:28 credit10ms 900
2017-05-25 14:02:33 fhtbuf AE
2017-05-25 14:02:44 raw No answer
2017-05-27 04:25:04 state Initialized
2017-05-25 14:02:52 uptime 0 00:00:06
2017-05-25 14:02:57 version V 1.67 nanoCUL868
Attributes:
rfmode KOPP_FC
List SwichTreppe
Internals:
CFGFN
DEF 20 D7C1 04
IODev KoppCUL
KEYCODE 20
KoppCUL_MSGCNT 16
KoppCUL_RAWMSG kr07D7C13920CC0F0465
KoppCUL_TIME 2017-05-27 04:25:04
LASTInputDev KoppCUL
MSGCNT 16
NAME SwitchTreppe
NR 100
STATE off
TIMEOUT 00000
TRANSMITTERCODE1 D7C1
TRANSMITTERCODE2 04
TYPE KOPP_FC
Code:
1 D7C1 20
stop D7C1 F7
Readings:
2017-05-27 04:25:04 state off
Attributes:
IODev KoppCUL
group Switch
model Timer_8080_04
room KOPP
hab nen Timer 8080.04 konnte aber noch nicht schalten.
Ich habe es jedoch auch noch nicht Testen können nachdem ich auf model Timer_8080_04
Umgestellt habe.
hoffe ich komme morgen mal zum Testen.
Falls Du Hilfe benötigst, schicke mir am besten den entsprechenden Auszug aus Deiner fhem.cfg
Gesendet von meinem SM-G900F mit Tapatalk
Hallo RaspII,
ok werde ich machen wenn ich nicht weiter komme.
Hallo RaspII,
ich schnall es leider nicht.
hab meinen TreppenSwicht (Timer) eingerichtet im Fhem Log werden die Signale die vom Bewegengsmelder kommen und den Timer schalten auch erkannt aber wenn ich den swich im Fhem schalte geht das Treppen Licht nicht an.
was kann ich dir alles liefern um meinen Fehler zu Finden.
sorry bin noch nicht ganz so tief in Fhem drin also bitte sag mir welche Sachen du aus der Fhem.cfg und dem Log benötigst oder reichen Listings der Geräte ?
Hi,
Ich bin grad im Urlaub,
melde mich am Sonntag.
Gesendet von meinem SM-G900F mit Tapatalk
Hi raspII,
alles klar eilt nicht nen wunderschönen Urlaub ;-)
Hallo Powertrain01
sorry, ich wollte mich gleich im Juni bei Dir melden, ich hatte das völlig vergessen.
Läuft das System inzwischen bei Dir oder gibt es noch die selben Probleme?
Ich habe mir mal meinen Code angeschaut.
So wie es aussieht habe ich das Model 8080.04 noch nicht vollständig implementiert, man kann es dummerweise aber schon auswählen.
Ein Tastendruck (Klick auf On bzw. das Lampensymbol) sollte einem kurzen Tastendruck der Fernbedienung/des Switches entsprechen, d.h. dass der einprogrammierte Timer sollte gestartet werden.
Testen kannst Du das ganze aber auch im RAW Mode.
Dazu musst Du aber die FHEM.cfg editieren.
Dort suchst Du Deine Definition von "SwichTreppe"
Vor diesem Abschnitt am besten einen Zweiten Schalter als Testdevice anlegen, der Code müsste wie folgt aussehen:
define SwichTreppe2 dummy
attr SwichTreppe2 eventMap on off
attr SwichTreppe2 group Lampen
attr SwichTreppe2 icon scene_garden
attr SwichTreppe2 room KOPP
define SwichTreppe2_In_Action notify SwichTreppe2 set CCD raw kt20D7C10400000N
define SwichTreppe2DauerEin dummy
attr SwichTreppe2DauerEin eventMap on off
attr SwichTreppe2DauerEin group Lampen
attr SwichTreppe2DauerEin icon scene_garden
attr SwichTreppe2DauerEin room KOPP
define SwichTreppe2DauerEin_In_Action notify SwichTreppe2DauerEin set CCD raw ktA0D7C10406000N
Der erste Block "SwichTreppe2" definiert wieder einen kurzen Tastendruck, d.h. der Timer sollte gestartet werden
Der zweite Block "SwichTreppe2DauerEin" soll den langen Tastendruck simulieren, d.h. den Switch auf "Dauer Ein" schalten (klappt nur wenn er vorher aus war).
Die letzten 5 Zahlen vor dem "N" bestimmen die länge des Tastendrucks in msec. (hier 06000 = 6000msec = 6sec).
Der zweite Block war auch der Grund warum ich den Timer noch nicht im Modul implementiert habe. Bei meinem Timer war es nahezu unmöglich, die Zeit für "Dauer Ein" zu treffen.
War die Zeit minimal zu groß definiert oder minimal zu klein ging der Timer kurz an und sofort wieder aus. Das war auch bei Nutzun der Fernbedienung so, evt. ist mein Timer defekt.
Bei meinen Definitionen bin ich davon ausgegangen, dass Dein Switch folgende RAW-Message gesendet hatte:
RAWMSG kr07D7C13920CC0F0465
Dann bin ich mal auf Deine Antwort gespannt.
Gruß
RaspII
Hallo zusammen,
bin durch die Suche auf diesen Thread gestoßen und habe ein paar Fragen zu Kopp Free Control. Ich hoffe ihr könnt mir helfen.
Habe einen Free Control Funkempfänger mit Dimmfunktion vom Typ 8012 (steht so auf dem Gehäuse)
Dazu habe ich einen Wandschalter vom Typ 822X. Steht so auf dem Schaltermodul.
Beides zusammen funktioniert perfekt. Ein-Dimmen-Aus.
Will nun den Wandschalter in FHEM einbinden. Habe einen NanoCul 868 mit rfmode Kopp_FC und Firmware V1.67 868 im Betrieb.
1.Frage. Wird der Wandschalter 822X überhaupt unterstützt? Kann in nicht in FHEM anlernen. Soll heißen es wird kein neues Gerät erkannt wenn ich einer der Tasten betätige. Autocreade ist aktiv.
2.Frage. Der Dimm-Aktor Typ 8012 ist im WIKI nicht aufgeführt. Wird er dann auch nicht unterstützt?
3. Frage. Kann es sein das meine Teile gar nicht unterstützt werden. Ich habe im Netz gelesen das es Free Control Version 1 und Version 2 gibt.
Gruß Uwe
Hallo Krottbacher,
1)
ich bin mir ziemlich sicher, daß der Schalter funktioniert. Ich bin mir aber nicht sicher ob "autocreate" funktioniert (habe diese Funktionalität zumindest nicht bewußt implementiert.
Wenn Du wie in der Wiki unter"Kopp Sender auswertet" vorgehst, kannst Du sehen ob sich die RAW Message bei Druck eines Schalters ändert.
2)
Diesen Aktor gab es noch nicht als ich implementiert habe, zumindest besitze ich den
Aktor nicht.
Ich hab mir eben kurz die Beschreibung angesehen, mit dem Modell 8011 sollte es auch klappen.
Wie ist der Wandschalter angelernt? Mit einer Taste (nur Dimmen) oder mit 2 bzw 3 Tasten?
3)
Doch, nach kurzem Review der Anleitung sollte es gehen, aber ich schau nochmal nach ob ich Detailinformationen finde
Gesendet von meinem SM-G900F mit Tapatalk
Hallo RaspII,
leider verändert sich nichts bei RAW wenn ich einen der Taster drücke. Hier mal meine define vom NanoCul. Nicht wunderen das der Cul nanoCulMax heißt. Er war vorher für MAX -Sensoren eingestellt.
defmod nanoCULMax CUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A506926M-if00-port0@38400 1234
attr nanoCULMax rfmode KOPP_FC
attr nanoCULMax room Gateways
setstate nanoCULMax 2017-07-25 18:06:18 ccconf freq:868.300MHz bWidth:162KHz rAmpl:42dB sens:8dB
setstate nanoCULMax 2017-07-25 18:04:06 cmds A B C E e F f G h i K k l M m R T t U V W X x Y Z z
setstate nanoCULMax 2017-07-07 16:27:36 credit10ms 792
setstate nanoCULMax 2017-07-07 16:56:30 raw No answer
setstate nanoCULMax 2017-07-25 18:06:18 state Initialized
setstate nanoCULMax 2017-06-23 19:10:15 uptime 0 00:04:19
setstate nanoCULMax 2017-07-21 18:13:03 version V 1.67 nanoCUL868
Der Wandschalter ist als 1Taster nur dimmen eingestellt.
Hast Du mal einen Refresh vom Screen gemacht?
Gesendet von meinem SM-G900F mit Tapatalk
Ja, habe ich. Nix kommt. Habe auch den Abstand vom Sender zum NanoCul auf 2m reduziert. Nix kommt.
Welche Widerstände hast du als Spannungsteiler auf dem Nanocul? Siehe "https://wiki.fhem.de/wiki/Selbstbau_CUL"
470 Ohm und 1k?
Mit den größeren Werten gab es immer mal wieder Probleme
Gesendet von meinem SM-G900F mit Tapatalk
Habe 1k und 470Ohm für den Spannungsteiler eingesetzt. Habe so 2 NanoCuls für Fs20 und Max gebaut und erfolgreich im Betrieb.
Dann bin ich etwas ratlos, müsste auf den ersten Blick funktionieren.
Warum eigentlich "defmod" und nicht "define"?
Gesendet von meinem SM-G900F mit Tapatalk
Danke erst Mal für deine schnelle Antworten. Defmod wird geschrieben wenn man die Funktion RAW Definition am unteren Rand von Fhem benutzt.
Gruß Uwe
Hab das noch nicht verstanden, muss ich nomal nachlesen.
Hast Du mal ins Logfile geschaut ob das Kopp Modul Fehler Infos meldet?
Gesendet von meinem SM-G900F mit Tapatalk
Hier Auszug aus dem Logfile:
nanoCULMax device opened
2017.07.25 20:56:30 2: Switched nanoCULMax rfmode to KOPP_FC
2017.07.25 20:56:30 3: nanoCULMax: Unknown code krS-ReceiveStart, help me!
2017.07.25 20:57:46 2: Switched nanoCULMax rfmode to MAX
Was soll das bedeuten bei nanoCULMax: Unknown code krS-ReceiveStart, help me!
Zitat von: Krottbacher am 25 Juli 2017, 21:07:11
Hier Auszug aus dem Logfile:
nanoCULMax device opened
2017.07.25 20:56:30 2: Switched nanoCULMax rfmode to KOPP_FC
2017.07.25 20:56:30 3: nanoCULMax: Unknown code krS-ReceiveStart, help me!
2017.07.25 20:57:46 2: Switched nanoCULMax rfmode to MAX
Was soll das bedeuten bei nanoCULMax: Unknown code krS-ReceiveStart, help me!
Das würde bedeuten Dein Nanocul beherrscht das Kopp Protokoll nicht?
Gesendet von meinem SM-G900F mit Tapatalk
Hast Du die aktuellste FW drauf?
Gesendet von meinem SM-G900F mit Tapatalk
Wie das denn? Habe 1.67 drauf. Ist das nicht aktuell?
Ich hab selbst keinen NanoCUL, wo hast Du die FW her? Ich kann dann nachschauen ob Kopp drin ist
Gesendet von meinem SM-G900F mit Tapatalk
Oh je. Bin noch nicht solange dabei. Habe sie aus dem Netz. Wo genau muss ich nachschauen. Ich dachte es gibt nur eine Quelle. Kannst du mir vielleicht die Quelle sagen wo ich die Neuste Version finde?
Hab mal nachgeschaut,
Die Version wurde nicht mit jeder Änderung hochgezählt.
Einfach mal das aktuelle Hex File von Ende 2016 flashen, damit sollte es tun
Gesendet von meinem SM-G900F mit Tapatalk
https://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/nanoCUL/
Gesendet von meinem SM-G900F mit Tapatalk
Ich glaube wir kommen der Lösung immer näher. ich werde gleich morgen die Firmware neu flashen. Du hast mir sehr weitergeholfen. Werde morgen berichten ob ich erfolgreich war.
Nochmals vielen Dank für deine Hilfe.
Gruß Uwe
So, habe den NanoCul komplett neu geflasht mit der Firmware aus dem Link.
Leider hat sich nichts verbessert.
Im Logfile steht:
2017.07.26 19:14:39 2: Switched nanoCULMax rfmode to KOPP_FC
2017.07.26 19:14:40 3: nanoCULMax: Unknown code krS-ReceiveStart, help me!
Kannst du mal in die Firmware schauen, ob da überhaupt was von Kopp drin steht. Habe leider noch zu wenig Erfahrung und weiß nicht wie man das macht.
Hab nochmal nachgeschaut:
"krS-ReceiveStart" ist die Antwort vom CUL wenn er den Kopp Empfangsmode aktiviert hat. Dein FHEM ist auf aktuellem Stand?
Gesendet von meinem SM-G900F mit Tapatalk
Ja, hab alles auf dem neuesten Stand.
Dann muss ich mal in Ruhe nachdenken, bin aber noch einige Zeit anderweitig beschäftigt
Gesendet von meinem SM-G900F mit Tapatalk
Okay, kein Problem. Ich möchte mich trotzdem für deine Unterstützung bedanken. Hab ja noch viele andere Dinge in Fhem vor.
Gruß Uwe
Eine Idee habe ich noch,
In deiner Log Datei steht:
"2017.07.25 20:57:46 2: Switched nanoCULMax rfmode to MAX"
kann es sein dass in Deiner fhem.cfg Datei dem nanoCULMax noch der rfmode "MAX" als Attribut zugewiesen wird?
Falls ja dann bitte die entsprechende Zeile auskommentieren
Gesendet von meinem SM-G900F mit Tapatalk
das war der Logfile Auszug vom 25.07.17. Dann habe ich ja am 26.07.17 neu geflasht. Schau auf Antwort vom 26.07.17:
Im Logfile steht:
2017.07.26 19:14:39 2: Switched nanoCULMax rfmode to KOPP_FC
2017.07.26 19:14:40 3: nanoCULMax: Unknown code krS-ReceiveStart, help me!
Das stand im alten logfile auch schon, das attribute rfmode max kam später im logfile. Das hängt nicht von der culfw ab sondern von der fhem.cfg
Gesendet von meinem SM-G900F mit Tapatalk
Wenn du auf der Fernbedienung eine Taste drückst müsstest du im logfile eine Fehlermeldung ähnlich unknown code kr07....... finden. Das würde bedeuten, dass in FHEM das Module kopp_fc nicht (mehr) läuft. Wenn nach kopp_fc in FHEM das MAX Protokoll geladen wird wäre das die Erklärung
Gesendet von meinem SM-G900F mit Tapatalk
Hallo nochmal,
ich habe eben in meine FHEM Software geschaut. Die Meldung:
"2017.07.26 19:14:40 3: nanoCULMax: Unknown code krS-ReceiveStart, help me!"
könnte auch durch einen Bug in meiner Software verursacht sein, dann müsste das Kopp Protokoll aber dennoch problemlos laufen.
Ich habe derzeit keinen Zugriff auf meinen eigenen FHEM Server und kann das deshalb nicht testen/debuggen.
Die richtige Vorgehensweise für Dich wäre:
1) sicherstellen, dass in der fhem.cfg dem nanoCULMax kein anderes Protokoll zugewiesen ist wie kopp_fc
2) dann muss sich mit der aktuellen nanoCUL Firmware die RAW Message ändern wenn du unterschiedliche Taster drückst und ggf. einen Refresh der Seite machst
3) Wenn das alles nicht klappt, muss trotzdem im Logfile ein Empfang oder eine Fehlermeldung vermerkt sein. Im Text "kr07....." ist dann die RAW Botschaft enthalten.
Wenn Du trotzdem keinerlei Hinweise auf einen Empfang hast, hilft nur noch ein gemeinsames "online debuggen", bei mir klappt das frühestens in ca. 10 Tagen
Gesendet von meinem SM-G900F mit Tapatalk
Hi,
sorry das ich erst jetzt antworte. Hatte geschäftlich viel zu tun. Schaul mal, das steht in meiner Config:
define nanoCULMax CUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A506926M-if00-port0@38400 0000
attr nanoCULMax rfmode KOPP_FC
attr nanoCULMax room Gateways
define CUL_MAX CUL_MAX 123456
attr CUL_MAX IODev nanoCULMax
attr CUL_MAX room Spezial
Kann es sein das trotz der rfmode KOPP_FC die vorletzte Zeile da nicht hin gehört? Wenn ja soll ich die einfach löschen?
Noch eine Frage: Wenn ich doch das attr Kopp_Fc auswähle und speichere, dann kann doch gar kein anderes Protokoll als das zugewiesen werden. Oder wie soll das gehen?
Gute Frage,
Ich hätte erwartet, dass das letzte zugediesene Protokoll aktiv bleibt.
Deine letzten 3 Zeilen kann ich absolut nicht nachvollziehen.
"
define CUL_MAX CUL_MAX 123456
attr CUL_MAX IODev nanoCULMax
attr CUL_MAX room Spezial"
Wie kann ein define auf sich selbst verweisen?
Kommentiere die 3 Zeilen mal aus. Hast fu im Logfile "kr..." Infos gefunden?
Gesendet von meinem SM-G900F mit Tapatalk
Hi,
wollte mich nochmal melden.
Gibt es noch Bedarf bzgl Support oder kannst Du inzwischen auch Botschaften empfangen?
Habe heute Abend ab 20:00 etwas Zeit
Gesendet von meinem SM-G900F mit Tapatalk
Hi,
sorry das ich erst jetzt reagiere. War im Urlaub. Habe nach wie vor Interesse aber leider ist mein System down. Habe große Problem mit dem W-Lan und der Fritz Box. Das System klinkt sich immer wieder aus. Muß erst das Problem lösen. Ich melde mich sicher wieder. Finde es super das du mir helfen willst. :)
Gruß Uwe
Ich habe jetzt mit der SDR Software und einem Stick eine Frequenzabweichung zwischen CUl und der Kopp-FB festgestellt.
Der CUL sendet auf 868,300 MHz und die Kopp-FB auf 868,260 MHz. Das könnte meiner Ansicht nach die Ursache sein, dass ich mit dem CUL-V3 Und der culfw 1.67 keine Kopp-Protokolle empfangen kann. Allerdings weiß ich nicht, wie ich in der culfw die Freuwnz ändern kann (Ändern in der Quelle und neu kompilieren). Kann mir vielleicht jemand helfen und die Frequenz in der culfw anpassen?
Eine Änderung der Register (0F,10,11) mittels Terminalbefehl hatte leider keine Auswirkungen.
Hi,
die Kopp Sender scheinen nicht allzu Frequenzgenau zu sein.
Meine Sender senden z.B. auf 868,316 und 868,310 Mhz (gemessen mit einem sehr genauen SDR Stick).
Kopp selbst gibt in seinen technischen Infos 868,3Mhz an (Bandbreite 50kHz).
Ich würde nicht empfehlen die Frequenz zu ändern, mit originalen CUL Sticks gab es meines Wissens auch nie Probleme.
Kannst Du Deine FB in FHEM empfangen (siehe Log Datei)?
Nein, ich kann keine Telegramme von meiner Kopp-FB empfangen.
Habe zur Sicherheit aber auch den Empfang von Homatic-Telegrammen ausprobiert, um die Funktionsfähigkeit des CUL zu testen - das hat funktioniert.
Ich denke, dass es schon an der Frequenzabweichung liegt, da die Kopp-FB auch ziemlich schmalbandig sendet.
Ich kann mir gar nicht vorstellen, dass das nicht funktioniert.
Wir können gerne gemeinsam Debuggen.
Wie hast Du das KOPP Feature in Betrieb genommen / konfiguriert?
Welche Einträge gibt es in der Log Datei wenn Du den Sender bedienst?
Ehrlich gesagt habe ich den Stick an einer CCU2 (auch mit entsprechender USB-Kabelverlängerung).
Über das CuxD-Terminal starte ich dann per "krS" den Kopp-Protokoll-Empfang, da ich vor der weiteren Einrichtung erst einmal die Telegramme meiner Aktoren mitlesen wollte.
Mach ich da was falsch?
Hi,
wenn das CuxD-Terminal wie ein normales Terminal am CUL-V3 hängt, sollte es funktionieren.
Bekommst Du als Antwort die Botschaft:"krS-ReceiveStart"?
Du kannst auch mit "krS1" oder "krS2" einen Debug Mode starten, dann der CUL Dir alle empfangenen Daten
Welche KOPP FB hast Du eigentlich (Es gab da wohl auch ein älteres KOPP System, keine Ahnung ob das Alte/Neue-System zueinander kompatibel sind
Falls Du doch mal die 868,260 MHz ausprobieren willst:
Einfach die culfw mit folgender (siehe Anhang) kopp-fc.c neu übersetzen.
Wenn Du wissen möchtes was geändert wurde, suche im Source File nach Deinem Namen
Hi Raspii,
erst einmal vielen Dank für deine Bemühungen.
Ich habeeine ältere FB, nach Recherchen im Internet scheint es aber keine Unterschiede im Protokoll zu Neueren zu geben, da Kompatibilität seitens Kopp versprochen wird.
Ich habe auch schon mit ,,krS1" u. ,,krS2" probiert, habe aber trotzdem keinen Empfang. Wenn ich die Kommandos eingebe antwortet der CUL auch mit antwortet ,,Receive Start", insofern alles ok.
Mit dem neu übersetzen habe ich noch nie gemacht, mal sehen, ob ich das hinbekomme, aller Anfang ist schwer.
Habs mal für dich für 868,260 MHz übersetzt (aber nicht getestet).
Hast Du eigentlich mal nachgeprüft ob Du senden kannst (irgend einen meiner Beispiel Strings und den mit SDR empfangen)?
Noch eine Anmerkung:
Es gibt wohl 2 Protokolle die nicht zueinander kompatibel sind
a) Version 1
b) Version 2
ich unterstütze nur die Version 2.
Man sieht das am Symbol auf der Fernbedienung, siehe Bild
Hi RaspII,
Nochmals vielen Dank für deine Bemühungen.
Wenn das mit den zwei Versionen so ist, da habe ich wohl die Version 1.
Dann ist es kein Wunder, dass das nicht funktioniert, schade.
Ja, das erklärt einiges.
Ich habe leider keine Version 1 vefügbar, ansonsten könnte ich mir mal anschauen ob ich das einfach implementieren könnte.
Allerdings habe ich bis Herbst 2019 kaum Zeit für größere Aktivitäten.
Kannst Du mir evt. ein Bild Deiner FB und eines Aktors anhängen (habe die alte Versionen noch nie zu Gesicht bekommen).
Hi RaspII,
im Anhang habe ich dir ein Bild der alten Version (FB + Schaltaktor) beigefügt.
Die Kopp Steuerung sendet theoretisch auf 868,33795166 MHz mit einer Bitrate von 4,79793548584 kbps, das sind zumindest die Werte, die in den Chip programmiert werden.
Ich hatte mir 2014 mit einem FPGA einen SPI-Monitor geschrieben und die Daten als Hexdump auf einem VGA Monitor ausgegeben, so daß ich bequem mitlesen konnte, was der µC da so schickt. Es ist immer die gleiche Konfiguration, die eigentlichen Sendedaten werden synchron über GDO0 und GDO1 übertragen.
Siehe Anhang, das ist das komplette Protokol, wenn man eine Taste dre FB kurz drückt.
Ich schau mir das mal ab Herbst an.
(Wenn es auf den Winter zugeht hab ich vermutlich mehr Zeit)
:-)
Hallo RaspII,
hattest du eventuell schon einmal Zeit dich mit der Thematik zu befassen?
Hallo Kanumouse,
nein, bisher noch nicht, ich habe das Thema aber nicht vergessen. Wenn alles klappt kann ich Ende nächster Woche mein aktuelles Projekt abschließen, dann könnte es losgehen.
Ansonsten wird es frühestens im Februar starten.
Du könntest bis dahin helfen möglichst viele Informationen über das System zu sammeln,
ich habe bisher keinerlei Info's über die Unterschiede zum neuen System
(Datenblätter, verwendeter Sende/Emfangsbaustein, nebenher kann ich mich dann schon ab sofort etwas einlesen).
Sollte der gleiche Senderbaustein benutzt werden wie bei der aktuellen Version, könnte ich dir schon in den nächsten Wochen eine Testsoftware erstellen, Deine Protokollmitschriebe sollte ich dann aber für diese Arbeit haben. Nachtrag: habe eben gesehen, dass Du schon eine init angehängt hattest, wie ist die Bezeichnung des Baussteins den Du mitprotokolliert hast, ist es ebenfalls ein CC1101)?
Für weitergehende Aufwände (debuggen oder Prozokollanalysen etc) kann ich mir gerade keine Zeit abzwacken.
Gruß
Hallo nochmal,
habe mir eben Deine Kopp_init.txt gegen die Sequenz des neuen Senders verglichen.
Das Ergebnis überrascht mich etwas, die Sequenzen sind praktisch identisch (Minimale Abweichungen bei der Frequenz, sonst identisch).
Den eigentlichen Sendevorgang (Bitstream) erfolgt vermutlich nicht über die Register (sonst würde man das im Protokoll sehen) sondern erfolgt vermutich über einen Pin am (CC1101?). Diesen kann man nur direkt an den FB monitoren.
Hast Du hier eine Möglichkeit das bei Deinem Sender zu tun?
Hallo RaspII,
leider kann ich das nicht.
So tief reichen dbzgl. meine Fähigkeiten nicht.
Gruß
Hm, dann wird es generell schwierig, ich habe das alte System nicht zur Verfügung.
Ich überlege mir mal ob ich eine "TestFirmware" für den CUL schreiben kann, die auf "Bitebene" mitloggt, einfach wird das nicht.
Ich melde mich wieder sobald ich mich an die Arbeit machen kann.
Hallo Kanumouse,
ich habe mein "Projekt" jetzt tatsächlich abschliessen können und bin schon mitten in Deiner Problemstellung drin.
Meine Idee ist, mit einem Signalduino (das ist eine andere Firmware auf den Nanocul) die Bitfolge Deiner Fernbedienung mitzuschreiben.
Dafür bin ich gerade mit den Signalduino Kollegen in einem eigenen Thread unterwegs.
Du kannst unsere Aktivitäten hier verfolgen: https://github.com/RFD-FHEM/RFFHEM/issues/711# (https://github.com/RFD-FHEM/RFFHEM/issues/711#)
Du hast einen Nanocul verfügbar, den Du dann umflashen kannst?
?
Hallo Raspi,
leider bin ich jetzt zum Jahresende arbeitsmäßig ziemlich beansprucht, so dass ich lange nicht ins Forum geschaut habe.
Einen Nanocul habe ich leider nicht, sondern nur einen Cul.
Aber ich denke, dass sollte zum Schluss nicht das Problem sein, einen zu besorgen.
Ok
Du könntest mir auch einen Sender (optional auch ein Empfangsteil) zusenden, dann fallen zwar Portokosten an, aber das Debuggen wäre dann einfacher.
Hallo Kanumouse,
ich habe jetzt noch anstelle der Signalduino Version eine nanoCUL Version gebaut, die deutlich besssere Eigenschaften hat.
Runterladen kannst Du diese Version Hier:
https://forum.fhem.de/index.php/topic,82379.msg1004482.html#msg1004482 (https://forum.fhem.de/index.php/topic,82379.msg1004482.html#msg1004482)
Mit dem Befehl:
krS3
(am besten direkt an einem Terminalprogamm eingeben, nicht via FHEM)
sollten alle Botschaften protokolliert werden.
Danach einfach hier posten.
Ich bau Dir auch eine Testvariante für den CUL, kein Problem.
Welche Version hast Du?
CUL V3?
Hallo RaspII,
das wäre toll.
Ich habe die CUL V3.
Here it is:
Hallo RaspII,
ich habe den CUL-Stick mit deiner Softwarevariante geflasht.
Leider kann ich trotzdem keine Rohtelegramme empfangen.
Es wir wohl das Beste sein, wenn ich dir einen Handsender und einen Empfänger zusende.
Hallo,
können wir so machen.
Aber lansam befürchte ich, dass Du auch "Opfer" der blauen CC1101 Module geworden bist.
Kannst Du mir bitte vorher noch ein Bild von Deinem NanoCul hier posten?
Hallo RaspII,
ich habe eine CUL-Stick von Busware, insofern glaube ich nicht, dass ich von dem Problem betroffen bin.
Die Fotos habe ich als Anhang beigefügt.
Gruß
Hallo nochmal,
Ich befürchte ich hatte da was falsch verstanden.
Die Kopp init Textdatei aus folgendem Beitrag war gar nicht von Dir?
https://forum.fhem.de/index.php/topic,47846.msg922919.html#msg922919 (https://forum.fhem.de/index.php/topic,47846.msg922919.html#msg922919)
Dann muss das auch nicht funktionieren
Ich schicke dir meine Adresse per Privater Nachricht
Hallo RaspII,
die Kopp Init Textdatei war nicht von mir.
Ich werde dir einen Handsender und einen Empfänger zusenden.
der Empfänger ist auf die Tasten 3 und 4 des Handsenders angelernt.
Es wäre toll, wenn das zum Schluß alles klappen würde.
Die Zeit ist sekundär.
Gruß
Hallo,
den ersten Schritt um die Botschaften zu empfangen habe ich mit Deinem Sender jetzt hinbekommen.
Läuft noch nicht 100%ig stabil, ich möchte aber gerne testen ob Frequenzen etc. auch mit einem zweiten Sender klappen.
Kannst Du bitte mal Testen ob Du ebenfalls Blöcke empfangen kannst und mir das Ergebnis zusenden?
Du musst dazu zwingend die Firmware, am besten via Terminal mit
krS2
in den Empfangsmode bekommen. In allen anderen Modis kommt vermutich nur Quatsch
Falls es klappt sende mir bitte für jeden Tastendruck (kurze und lange Drücke sollten unterschiedliche Botschaften generieren) das Ergebnis.
Anbei die erste Version.
Hallo,
ich habe die erste Version deiner Firmware getestet.
Im Ergebnis sind aus meiner Sicht schon Muster zu erkennen, aber in der Unterscheidung zwischen langem und kurzen Tastendruck scheinen mir die Blöcke nicht logisch.
Beim Empfang hat man den Eindruck, dass der eher zufällig ist, da es manchmal funktioniert und manchmal nicht, aber immerhin überhaupt erst einmal Empfang.
Manchmal empfängt man die Blöcke auch völlig abweichend von der folgenden Grundstruktur.
Empfangene Blöcke:
Kurzer Tastendruck
Taste 4 - B616CB6CAD800000
Taste 3 - B412CB6D05800000
Taste 2 - B402CB6C25800000
Taste 1 - B606CB6DA5800000
Langer Tastendruck
Taste 4 - B602CB6C04800000
Taste 3 - B416CB6DAC800000
Taste 2 - B402CB6C24800000
Taste 1 – B616CB6DAC800000
Gruß
Hi,
das sieht schonmal richtig gut aus und bestätigt auch meine Befürchtungen.
Ein Erfolg ist, dass überhaupt was kommt, d.h. die ersten beiden Bytes 0x09 und 0x64 werden ab und zu empfangen, sonst würde kein Sync ausgelöst und auch nichts ausgegeben.
Das Problem mit den Unterschiedlichen Ausgaben ist, dass ich die Baudrate nicht richtig treffe.
Und das war auch meine Vermutung. Da die Botschaftn per Software und nicht per Hardware erzeugt werden gibt es hier vermutlich Toleranzen, die nicht "Standard" sind (wenn man das überhaupt sagen kann).
Empfängt man die einzelnen Bits per Software macht das nichts, man kann die Zeiten ausmessen und so die Toleranz eleminieren.
Nutzt man wie ich das Fifo (Quasi im Sync Mode) muss man die Toleran der Hardware einhalten.
Die Tolereranz zu Deinem Sender ist bei mir ca. 2-3 %, das ist schon recht viel ohne Korrektur
Ich bin jetzt fast soweit, dass ich auch korrekte Botschaften (mit dieser Toleranz) senden kann, dann kann ich auch raustesten in welchem Rahmen der Empfänger tolerant ist.
Die Frage ist was Du damit vor hast.
Wenn Du aus FHEM raus nur senden möchtest könnte das schon reichen, wenn Du auch empfangen möchtest braucht sollte man die Bits ebenfalls per Software empfangen und den Fehler herausmessen.
Dann sollte die Basis aber nicht meine Standard Kopp Software sein, sondern eher ein Signalduino. Damit wäre es dann sogar möglich mehrere unterschiedlichen Protokolle (mit ASK/OOK Modulation) parallel zu fahren.
Ich frag dann bei den Signalduino Kollegen nach, ob es dort Ideen gibt.
Jetzt mach ich mich noch an die Senderoutine, vielleicht klappt das heute Abend ja schon.
Nachtrag:
Schade, dass Du noch keinen DBV-T Stick hast. Sonst könnten wir uns die Unterschiede der Sender ansehen.
Hallo,
ich bin jetzt einen riesen Schritt weiter.
In meiner Software habe ich noch einen Fehler gefunden. Ich kann jetzt senden und die "Dose" schaltet zuverlässig.
Ich habe zwar auch noch Fehler drin die ich heute nicht mehr finde, aber einem Test sollte das nicht stören.
Der erste Schritt wäre:
den Empfang nochmal zu testen, ob Du mit der aktuellen Version Ergebnisse bekommst die reproduzierbar sind.
Du benötigst jetzt zum Aktivieren des V1 Modes einen anderen Befehl:
krT2
Danach (nur falls der Empfang dann zuverlässig klappt) sollten bei jedem Tastendruck reproduzierbare Botschaften kommen.
Bei mir ist das für Taste 3:
Bytes in Fifo: 0B Received Data: 92DB2596D96DB2D8000000
Bytes in Fifo: 0B Received Data: 92DB2596D96DB2D8000000
Bytes in Fifo: 0B Received Data: 92DB2596D96DB2D8000000
und Taste 4:
Bytes in Fifo: 0B Received Data: 92DB2596D96D92D8000000
Bytes in Fifo: 0B Received Data: 92DB2596D96D92D8000000
Bytes in Fifo: 0B Received Data: 92DB2596D96D92D8000000
Wenn ich dann jeweils via CUL für Taste 3:
ku92db2596d96db2d805000J
Und Taste 4:
ku92db2596d96db2d805000J
via Terminal eingebe, kann ich ebenfalls zuverlässig schalten
Probiers mal aus und sag Bescheid
Hallo Kanumouse,
ich habe die Firmware jetzt soweit fertiggestellt.
Mit Deinen Komponenten kann ich jetzt zuverlässig kommunizieren.
D.h. wir müssen jetzt nur noch einen Mode finden, bei dem alle Deine Sender verstanden werden (und alle Deine Kompenenten den CUL verstehen), d.h. ggf. an der Datenrate ändern.
Hier mein aktueller Stand, die Vorgehensweise für Dich wäre immer noch wie im letzten Kommentar beschrieben.
Dann los gehts !
Hi RaspII,
hatte gestern Abend deine Version 002 ausprobiert.
Der CUL empfing die Blöcke unzuverlässig. Eine nachvollziehbare Logik konnte ich nicht erkennnen.
Jetzt eben habe ich deine Version 003 getestet.
Gleiches Verhalten - Empfang unzuverlässig bzw. gar nicht.
Den Test habe ich auch mit zwei verschiedenen Wandtastern, die ich noch im Einsatz habe, wiederholt - das gleiche Ergebnis.
Der Vollständigkeit halber habe ich dir einen Auszug aus dem CuxD-Terminal beigefügt.
11:14:18 [ttyACM0] *** connect(9600:8N1) CUL868
11:14:18 [ttyACM0] <-- V
11:14:18 [ttyACM0] --> V 1.67 CUL868
11:14:18 [ttyACM0] <-- X21
11:14:26 [ttyACM0] <-T krT2
11:14:26 [ttyACM0] --> krS-ReceiveStart
11:15:11 [ttyACM0] --> Bytes in Fifo: 08 Received Data: B4024B6C96C00000
11:15:38 [ttyACM0] --> Bytes in Fifo: 08 Received Data: B6024B6C96C00000
11:15:40 [ttyACM0] --> Bytes in Fifo: 08 Received Data: B6024B6C96C00000
11:18:09 [ttyACM0] <-T krE
11:18:09 [ttyACM0] --> krE-ReceiveEnd
11:18:43 [ttyACM0] <-T krT2
11:18:43 [ttyACM0] --> krS-ReceiveStart
11:19:43 [ttyACM0] <-T krE
11:19:43 [ttyACM0] --> krE-ReceiveEnd
Mache ich da irgend etwas falsch?
Gruß
Hallo Kanumouse,
so schlecht sieht das gar nicht mal aus.
Wenn man die Botschaften um 3 Bit nach links schiebt, sehen die letzten Bytes wie bei mir aus.
Zumindest sieht es besser aus wie beim letzten mal, d.h. die Baudrate habe ich in die richtige Richtung geschoben.
(jetzt wird es aber langsam kritisch, viel weiter komme ich nicht ohne dass Dein anderen Sender aus dem Fokus kommt).
Aber der Protokollanalyser sagt mir eigentlich das gleiche, ich liege noch nicht beim sollt.
Das zweite Problem dürfte das Sync-Byte sein. Ich synce gerade auf 0x09 und 0x64, 0x09 scheint die Blocklänge zu sein.
Wenn Das wirklich die Blocklänge ist und Dein sender nur ein anderes 2tes Byte schickt, finden wir vielleicht eine Lösung.
Ich mache mal eine V004.
Wenn Du die nächsten ein bis zwei Stunden Zeit hättest, könnten wir ein paar Tests fahren und sind dann heute evt. sogar schon erfolgreich.
Ich hänge die neue Version später an diesen Kommentar dran
Ok.
So,
ich synce jetzt auf 0x00 0x09, d.h. falls 0x09 die Blocklänge ist, müsste auch bei Dir was halbwegs sinnvolles kommen.
Die Baudrate habe ich auch nochmal um ein inkrement angepasst.
Das Problem ist, dass wir jetzt eigentlich nur noch ein "echtes" Sync Byte haben, d.h. es können sich jetzt leichter falsche Botschaften einschleichen (bei OOK Modulation ist kein Signal = 0 also immer das erste Sync Byte) :(
Bin mal gespannt was bei Dir jetzt ankommen.
Nachtrag:
bei mir ist das Problem schon sichtbar, ich empfange jetzt sporadisch falsche Syncs/Botschaften. Das ist aber noch kein Problem, die kann man später rausfiltern, weil extrem selten 2x die selben Botschaften empfangen werden.
Hallo RasPII,
mit der Version 004 empfange ich jetzt bei jedem Tastendruck 2 Blöcke.
Ich habe die Tasten in folgender Reihenfolge betätigt: 1, 2, 3, 4
13:06:24 [ttyACM0] --> Bytes in Fifo: 08 Received Data: 6C96B25B25B2D6DB
13:06:25 [ttyACM0] --> Bytes in Fifo: 08 Received Data: 6C96B25B25B2DADB
13:06:35 [ttyACM0] --> Bytes in Fifo: 08 Received Data: 6C96B25B25B2DE5B
13:06:35 [ttyACM0] --> Bytes in Fifo: 08 Received Data: 6C965B5B25B2DB5B
13:06:45 [ttyACM0] --> Bytes in Fifo: 08 Received Data: 6C96B25B25B2F6CB
13:06:45 [ttyACM0] --> Bytes in Fifo: 08 Received Data: 6C94B25B25B296CB
13:06:50 [ttyACM0] --> Bytes in Fifo: 08 Received Data: 6C84125B25B2924B
13:06:50 [ttyACM0] --> Bytes in Fifo: 08 Received Data: 6C96125B25B2DA4B
13:06:51 [ttyACM0] --> Bytes in Fifo: 08 Received Data: 6C94B25B25B2B64B
13:06:55 [ttyACM0] --> Bytes in Fifo: 08 Received Data: 8178000000000000
Es werden aber jetzt auch Blöcke empfangen ohne das ich eine Taste betätige (z.B. der letzte Bock oben).
Gruß
Super, jetzt sieht das schon aus wie bei mir ;D
Das Du jetzt auch Blöcke empfangst ohne Tastendruck liegt wie gesagt am schlechteren Sync, das muss ich später per Software abfangen.
Der nächste Schritt ist jetzt, dass wir bei Dir die richtige Baudrate erwischen.
Hast Du immer die selbe Taste gedrückt?
Nein, nacheinander 1, 2, 3, 4.
Ok, du bekommst gleich eine neue Version.
Ich empfange dann 2 Bytes mehr, die müssten dann immer "0x00" sein.
Ausserdem korrigiere ich die Baudrate nochmal.
Dann bitte erst mal nur noch die selbe Taste drücken
Here it is.
schaun wir mal
Taste 1 2 x betätigt, beim ersten Mal 3 Blöcke empfangen, beim zweiten Mal 4 Blöcke empfangen.
13:43:15 [ttyACM0] --> Bytes in Fifo: 0B Received Data: 6C96595B25B2DB6DA00000
13:43:15 [ttyACM0] --> Bytes in Fifo: 0B Received Data: 2DB6920000000096C84B25
13:43:15 [ttyACM0] --> Bytes in Fifo: 0B Received Data: 6C965A5B25B2DB6DA00000
13:43:25 [ttyACM0] --> Bytes in Fifo: 0B Received Data: 4804100B25B2DB49200000
13:43:25 [ttyACM0] --> Bytes in Fifo: 0B Received Data: 0092DB6DA0000000096C84
13:43:25 [ttyACM0] --> Bytes in Fifo: 0B Received Data: 6C04105B25B2DB69600000
13:43:26 [ttyACM0] --> Bytes in Fifo: 0B Received Data: 6C96595B25B2DB6DA00000
Ok, ich muss mal nachdenken.
13:43:15 [ttyACM0] --> Bytes in Fifo: 0B Received Data: 6C96595B25B2DB6DA00000
13:43:15 [ttyACM0] --> Bytes in Fifo: 0B Received Data: 6C965A5B25B2DB6DA00000
13:43:26 [ttyACM0] --> Bytes in Fifo: 0B Received Data: 6C96595B25B2DB6DA00000
Die Botschaften die völlig daneben liegen sind nicht das Problem, hier syncen wir nur falsch (dazu finden wir eine Lösung).
Das Problem ist ist die 5A anstelle von 59.
5A = 0101 1010
59 = 0101 1001
Es ist irgendwie schon kurios, dass nur an einer Stelle mittem im Block ein Bit verschoben wird.
Ich versuche mal den Sync zu verbessern, danach kann man evt. eine Mehrheitsentscheidung treffen 8)
Wiederhole die Tests bitte noch mit angehängter Version.
Ich bin jetzt ca. 1h weg (Spätzle machen, Mittag essen), danach hätte ich noch etwas Zeit.
Ich habe mir gerade überlegt, dass wir via senden Testen könnten welcher Block der richtige ist, dazu müsste ich aber die Software dann nochmal ändern (damit ich beim Senden auch das Sync für Dich richtig mache).
Die ersten 3 Blöcke und die letzten 2 Blöcke wurden ohne Tastendruck empfangen.
Die mit 6 beginneden Blöcke waren das Ergebnis eines einmaligen Tastendrucks der Taste 1.
14:29:37 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 67000000000000000000
14:29:38 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 88000000000000000000
14:29:41 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 62000000000000000000
14:29:44 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 6C96FA5B25B2DB6DE000
14:29:44 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 6C96125B25B2DB696000
14:29:44 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 6C96581B25B2DB6DA000
14:29:44 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 6C04105B25B2DB696000
14:29:44 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 24800000000000000000
14:29:49 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 67000000000000000000
Ok, damit haben wir schonmal eine neue wichtige Info:
Bzgl. der Baudrate ist es schlechter geworden (gut, bei mir nämlich auch :) )
Ich habe die Baudrate jetzt nochmal korrigiert und zwar in die andere Richtung (minimal).
Jetzt müsste es ähnlich wie vorher sein, oder besser.
Am besten Du schaust nochmal nach, was beim Druck derselben Taste(1) jetzt ankommt.
Dann können wir jetzt auch gleich das "Senden" testen. Hast Du einen Schalter der auf Taste1 reagiert?
Falls ja, sende mal einen der beiden Blöcke (einfach ins Terminal kopieren) und schau ob Dein Schalter reagiert wichtig wäre zu wissen bei welchem Block.
a)
ku6C96595B25B2DB6DA005000J
oder b)
ku6C965A5B25B2DB6DA005000J
ggf. bitte mehrfach testen und den Schalter vorab mit der FB in die Gegenrichtung schalten ;)
Falls das klappt könntest Du via FHEM die Module schon steuern, den Empfang würde ich im ersten Schritt weglassen.
Im prinzip müsste die fhem.cfg dann folgendermassen aussehen, Annahme: Dein CUL ist als CUL_0 definiert:
# Test KoppV1 Senden (Dose Kanumouse)
# -----------------------------------
define Dose1 dummy
attr Dose1 eventMap on off
attr Dose1 group KoppV1
attr Dose1 icon light_stairs
attr Dose1 room KoppV1Test
define Dose1_In_Action notify Dose1:on set CUL_0 raw ku6C96595B25B2DB6DA005000N
define Dose2_In_Action notify Dose1:off set CUL_0 raw ku6C96595B25B2DB6DA005000N
die letzte Zeile muss natürlich noch mit Deiner "Zweiten Taste" für Ausschalten angepasst werden (und je nach Deinen Ergebnisse auch die zweitletzte Zeile)
Mach Dir wg dem Empfang nicht so viele Gedanken, der macht bei den Kopp Modulen nicht soviel Sinn, die Aktuatoren antworten nicht mit einem Status, d.h. man kann sowiso nur vermuten ob geschalten wurde oder nicht.
So richtig Sinn macht der Empfang nur, wenn man mit einer FB irgend etwas via FHEM steuern will. Ich steure z.B. Homematik Komponenten mit der Kopp FB
Aber das ist noch ein langer Weg, weil ich dazu die KOPP_FC.pm anpassen muss.
Ich muss jetzt ein paar familiären Verpflichtungen nachkommen, könnte aber heute abend ab etwa 20:00 Uhr weitermachen, falls nötig.
(kann man ja neben dem Tatort machen, zu viele Fehler werden deshalb hoffentlich nicht einschleichen)
Hallo,
ich habe jetzt die Version 007 getestet.
folgende Blöcke habe ich empfangen:
17:09:12 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 6C94B25B25B4B6DB6000
17:09:12 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 6C96DA5B25B2DADB6000
17:09:12 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 6C04125B25B0B6DB6000
17:09:12 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 6C04B25B25A0B6DB6000
17:09:26 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 40480000000000000000
17:09:38 [ttyACM0] --> Bytes in Fifo: 0A Received Data: D2000000000000000000
Die letzten beiden Blöcke wurden ohne betätigung einer Taste empfangen.
Die Senderichtung habe ich auch getestet.
Wenn ich vorher mit Taste 2 den Aktor schalte, kann ich mit dem Kommando ku6C965A5B25B2DB6DA005000J zurückschalten.
Mit Kommando ku6C96595B25B2DB6DA005000J passiert gar nichts.
Hi,
was ich noch nicht verstehe:
Bei mir läuft der Empfang sehr stabil (2-3 identische Botschaften je Tastendruck), auch wenn ich die Datenrate ändere.
Bei Dir geht es quer durcheinander.
Könnte es sein, dass Du mit Deinem Sender sehr nahe am CUL bist und den CUL übersteuerst? (bei mir ist es etwa 1m Distanz).
Dummerweise habe ich die bisherigen Einstellungen für die Datenrate nicht mitgeschrieben, ich fange mal damit an.
CUL_V3_KoppV1_007:
DRATE Mantisse: FB
DRATE Exponent: 05
CUL_V3_KoppV1_008:
DRATE Mantisse: FC
DRATE Exponent: 05
Teste mal welcher besser läuft (bitte auch den Abstand zum Empfänger vergrößern)
Ich hab noch ein paar Verbesserungen (hoffentlich) eingebaut:
ich mache eine zwei aus drei Auswahl, d.h. wenn zwei von drei Botschaften identisch sind akzeptiere ich ihn als gültig.
Das ist noch nicht perfekt, aber besser wie vorher.
Dazu musst Du allerdings
krT
eingeben und nicht krT2, krT2 reicht jeden empfangenen Block weiter (zu Debugzwecken).
Alle anderen Parameter habe ich nicht geändert
So, jetzt ist erst mal genug
Hallo RaspII,
ich habe jetzt die Tests mit der Version 009 gemacht.
Das Ergebnis sieht, wie folg aus:
Test mit krT, viermal Taste 1 hintereinander gedrückt:
19:11:33 [ttyACM0] --> kv6C96B25B25B2D6DB60
19:11:42 [ttyACM0] --> kv6C96125B25B2DADB60
19:12:05 [ttyACM0] --> kv6C96B25B25B2D6DB60
19:12:20 [ttyACM0] --> kv6C96B25B25B2D6DB60
Test mit krT, Taste 1, 2, 3, 4 hintereinander gedrückt:
19:14:37 [ttyACM0] --> kv6C84125B25B2D2DB60
19:15:20 [ttyACM0] --> kv6C96125B25B2D25B60
19:16:33 [ttyACM0] --> kv6C94125B25B2D24B60
19:16:40 [ttyACM0] --> kv6C94125B25B2D24B60
Test mit krT2, Taste 1:
19:26:49 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 6034024B6DB680000000
19:26:49 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 6C96B25B25B2D6DB6000
19:26:50 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 592CB25B4B65B6DB6000
krT2, Taste 2:
19:28:20 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 6C96B25B25B2D65B6000
19:28:20 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 6C04125B25B0925B6000
19:28:21 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 6C96B25B25B2DA5B6000
krT2, Taste 3:
19:29:12 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 6C96F25B25B2DACB6000
19:29:12 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 6C96B25B25B2B6CB6000
19:29:12 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 6C84B25B25B2D6CB6000
19:29:12 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 6C96B25B25B2D6CB6000
19:29:12 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 6C96B25B25B2DECB6000
19:29:12 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 6C96B25B25B2F6CB6000
krT2. Taste 4:
19:30:13 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 38000000000000000000
19:30:14 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 6C04125B25B2964B6000
19:30:14 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 6804125B25B0964B6000
19:30:14 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 6C94125B25B2924B6000
19:30:14 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 6C84B25B25B2B64B6000
19:30:15 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 6C04125B25A0924B6000
19:30:15 [ttyACM0] --> Bytes in Fifo: 0A Received Data: 6C96B25B25B2D64B6000
Hm,
sieht noch nicht so gut aus.
Bei krT muss je Taste jeweils die selbe Antwort kommen.
Ich teste mal mit einer leicht modifizierten Frequenz, vielleicht kann ich Dein Problem dann hier reproduzieren.
Kannst Du evt. raustesten, welcher Befehl (wenn Du sendest), zum Schalten der Aktuatoren führt (für Taste 1 kennen wir das ja schon).
bei Taste1 müsste das nach Statistik:
ku6C96B25B25B2D6DB6005000J sein.
ku6C965A5B25B2DB6DA005000J hat beim letzten mal geklappt, das passt alles irgendwie nicht zusammen.
Das ist jetzt ein Schuss ins Blaue.
Bei mir funktioniert auch das (keine Ahnung warum es bei mir nie kritisch wird)
Wenn mit dieser Version keine Änderungen bei dir sichtbar sind, sollten wir tatsächlich SDR# bemühen
Hallo RaspII,
ich habe jetzt den Test mit den beiden Befehlen durchgeführt. Leider passiert jetzt bei beiden nichts.
Inzwischen habe ich auch mit radio hacker Mitschnitte gemacht (für alle 4 Befehle des Handsenders und für die beiden Befehle vom CUL).
Im Übrigen hat deine Version 010 auch keine Verbesserung gebracht.
Die Mitschnitte kann ich ehrlicherweise nicht deuten und habe sie als Anhang beigefügt.
Gruß
Hallo,
die gute Nachricht:
Dein Sender sendet die selben Tastencodes wie der Sender bei mir.
Die Schlechte Nachrich:
Der CUL macht nur Schrott, evt. habe ich die Frequenz in die falsche Richtung verschoben.
Zumindest wissen wir jetzt, das Taste 1 =
96c96592d92d96db6d8
(9 ist die Blocklänge auf die wir synchronisieren, die wird von der Firmware ausgeblendet)
Im Bild ist:
oben: Handsender bei mir
mitte: Handsender bei Dir
unten: Dein CUL (das sieht bei mir aus wie bei Dir der Handsender)
Welche Version hast Du benutzt, die V10?
Wir könnten das ganze abkürzen, wenn Du mit SDR# die Frequenzen vom Sender und CUL vergleichst.
Weist Du was da zu tun ist?
Ich werde nicht so richtig schlau aus Deinen Messungen mit dem CUL.
Mit diesem Signal dürfte er eigentlich nie was empfangen evt. ist das ein Meßproblem.
Die V10 ist auf 868Mhz wenn ich mich richtig erinnere.
Sende mal mit dieser Version das Kommando:
ku6c96592d92d96db6d805000J
und schaue nach ob Dein Relais damit schaltet.
Falls nicht kannst Du es mit der angehängten Version nochmal testen (wäre aber eher Zufall wenn das was bringt).
Trotzdem bitte mit der neuen Version mal die Signalform mitschreiben und wieder hier posten
Nachtrag:
Bitte auch noch posten, was der CUL nach abschicken des Sendebefehls oben zurückmeldet
Hallo RaspII,
jetz bin ich auch so langsam am verzweifeln.
Die Mitschnitte hatte ich mit Verion 009 gemacht.
Bevor ich jetzt auf Version 011 gegangen bin, habe ich mit Version 010 die Frequenzen gemessen.
Frequenz Handsender: 868,2487MHz
Frequenz CUL: 868, 0020 MHz
Das Senden des Kommandos ku6c96592d92d96db6d805000 hat nicht zum Schalten des Aktors geführt.
Mit deiner neuen Version 011 geligt mir mit dem radio hacker leider keine Aufzeichnung. Warum, weiß ich nicht, ich habe das Gefühle da geht kein Sendeblock raus?
Den Handsender sehe ich im radio hacker immer.
Beim Senden des Kommandos habe ich im Terminal folgende Nachricheten:
14:14:35 [ttyACM0] --> commandlineparameter: ku6c96592d92d96db6d805000J
14:14:35 [ttyACM0] --> Stringlength: 26
14:14:35 [ttyACM0] --> Next Character (int) after parameter (should be line end character): 0
14:14:35 [ttyACM0] --> Amount of Bytes (Hex) found inside command line parameter: 11
14:14:35 [ttyACM0] --> Tick Timer: 00007CD7
14:14:35 [ttyACM0] --> KeyOffTime: 05000msec
14:14:36 [ttyACM0] --> KeyOffTime in ticks: 00000271[hex]
Hi,
das ist trotzdem schon mal eine Aussage.
Deine Frequenzmessung passt zu meiner Einstellung von V009, bei V011 und V012 müssten es 868,3Mhz sein.
Das Problem ist, dass ich hier nicht mit einem CUL teste sondern mit einem "ProMicroCUL", d.h. da könnte es schon noch unterschiede geben.
(Speicher CUL läuft über oder was in der ART).
Um sicherzugehen, das bei Deinem CUL die Ausgangsleistung korrekt eingestellt ist gibt es jetzt die Version 012,
Hier wird der Inhalt des PA-Table angezeigt.
Ausserdem könntest Du noch testen, ob es mit dem Empfang bei der V011 oder V012 jetzt reproduzierbarer ist (die Parameter müssten passen).
(kann gar nicht sein, dass wir das nicht hinbekommen)
Wie gesagt, bei mir funktioniert alles einwandfrei, Empfang, Senden. Die Abhängigkeit von der Frequenz ist bei mir minimal, auch die Toleranz bzgl. Baudrate ist relativ/ausreichend groß.
Hallo,
Ich habe jetzt mit Version 012 getestet.
Im radio hacker kann ich leider keinen Empfang sehen.
Die Nachrichten aus dem Terminal folgen:
15:13:22 [ttyACM0] --> commandlineparameter: ku6c96592d92d96db6d805000J
15:13:22 [ttyACM0] --> Stringlength: 26
15:13:22 [ttyACM0] --> Next Character (int) after parameter (should be line end character): 0
15:13:22 [ttyACM0] --> Amount of Bytes (Hex) found inside command line parameter: 11
15:13:22 [ttyACM0] --> Tick Timer: 0000404E
15:13:22 [ttyACM0] --> PA Table values: 0 129 0 0 0 0 0 0
15:13:22 [ttyACM0] --> KeyOffTime: 05000msec
15:13:22 [ttyACM0] --> KeyOffTime in ticks: 00000271[hex]
15:14:17 [ttyACM0] <-T krT
15:14:17 [ttyACM0] --> PA Table values: 0 129 0 0 0 0 0 0
15:14:17 [ttyACM0] --> krS-ReceiveStart
15:14:22 [ttyACM0] --> kv6C96B25B25B2DADB60
15:14:28 [ttyACM0] --> kv6C96B25B25B2D6DB60
15:14:28 [ttyACM0] --> kv6C96B25B25B2D6DB60
15:14:37 [ttyACM0] --> kv6C96B25B25B2D2DB60
Die letzten 4 Empfangsblöcke habe ich mit Tate 1 des Handsenders ausgelöst. Die scheinen jetzt reproduzierbar zu sein.
ok, ich hab den Fehler gefunden.
Hab Dir die falsche Info geschickt (copy Paste Fehler)
Du musst als Kommando
ku
schicken, nicht kv.
kv ist der Header des Empfangsblocks, sorry
Schicke mir dann bitte nochmal einen Mitschrieb, ob das Signal immernoch "Mist" ist
Ich habe als Kommando ku gesendet (siehe Terminal-Copy).
Die letzten 4 Blöcke mit kv sind empfangenen Blöcke vom Handsender
wäre wohl zu einfach gewesen :-(
Jetzt bin ich langsam auch am Ende.
Ich habe nach nachgeschaut, der Micro Prozesser vom ProMicro CUL ist mit dem CUL_V3 identisch (Atmega 32u4), d.h. wenn bei mir der Speicher reicht sollte es bei Dir auch funktinoieren.
Die PA-Table ist auch idenisch, dann muss auch gesendet werden.
Aber Deine letzte funktionierende Messung war quasi schrott, das kann ich mir echt nicht erklären.
Du bist sicher, dass nichts gesendet wird (die Verstärkung beim Universal RH ist komplett rechts?
Ich muss mich fürs erste mal abmelden, möchte noch in den Garten solange es hell ist.
Kein Problem!
Ich habe jetzt noch einmal versucht mit SDRSHARP die Sendung des CUL zu sehen.
Es ist aber kein Sendesignal zu sehen.
Ich glaube, mit Version 009 ging es noch..
Du bist bei 867,3 Mhz und nicht bei 868,3 ?
Hast Du auch 1Mhz weiter oben nachgeschaut?
Man sieht einige Signale bei Dir, das könnten Oberwellen (bzw. Unterwellen)
Bei mir klappt das problemlos, siehe:
Die Verstärkung habe ich bei SDR Sharp voll aufgemacht. Das ist zwar nicht nötig, aber zur Sicherheit.
Ok, kannst du recht haben.
Hab's noch einmal versucht.
Ein kleiner Empfang tis jetz zu verzeichnen (siehe Bild).
Ich habe schon darüber nachgedacht, ob vielleicht der Abstand zwischen Empfänger und CUL zu groß ist (ca. 8m)?
Kann ich aber leider nicht vekleinern, da der Empfaänger an meinem PC angeschlossen ist und der CUL im Hauswirtschaftsraum hängt.
Kann ich aber nicht so richtig verstehen, da der Empfang schon einmal besser war und das Schalten des Aktors schon einmal geklappt hat.
8m sind überhaupt kein Problem.
Wenns nicht schaltet auch nicht, es gibt definiert noch ein Problem mit der Baudrate, Deine Botschaften sind nahezu identisch:
kv6C96B25B25B2DADB60
kv6C96B25B25B2D6DB60
kv6C96B25B25B2D6DB60
kv6C96B25B25B2D2DB60
aber der Universal RH sagt bei Dir was anders, nur die ersten Daten sind korrekt, das deutet auf eine falsch Baudrate hin (die Fehler passieren bei längerer Botschaft sichtbar)
6c96592d92d96db6d8
da verrutschen die Bits nach dem 2ten Byte.
Wichtig wäre wenn Du nochmal mit dem Universal RH eine CUL Botschaft mitschreiben könntest (bei 868,3Mhz), dann könnte ich direkt vergleichen.
Wenn dort überhaupt nichts ankommt (mit max. Verstärkung), muss ich erst mal gründlich nachdenken,
Nachtrag2: Du kannst dann bitte noch ein Test machen und den Universal RH auf 868,2Mhz einstellen
Heute allerdings nicht mehr, ich muss jetzt weg.
Nachtrag:
die Info's vom Universal RH sind m.E. die richtigen, da die Tastencodes identisch zum Sender bei mir sind (Taste 1...4) und nur der Code des Senders selbst (alles was sich nicht ändert) sich unterscheidet.
Ich habe noch einmal getestet und mitgeschnitten, musste allerdings die Emfindlichkeit des RH deutlich hochnehmen.
Wenn ich das richtig deute, ist der Empfang jetzt im RH identisch mit dem gesendeten Block (ku6C965A5B25B2DB6DA005000J).
Hi,
was da an Signal ankommt ist eine Katastrophe und erklärt auch warum die Botschaften bei Dir dauern "springen".
Nur mal so ins blaue gefragt: könnte es ein, dass Dein CUL eine 433Mhz Version ist?
Hi,
ich habe den CUL von Busware als 868-Variante gekauft.
Ich habe auch noch einen CUL in der 433-Variante.
Rein äußerlich müsste das schon die 868-Variante sein, da die Antenne kürzer ist (L/4).
Dann fällt mir gerade nichts mehr ein, es sei denn es würde ein anderer Sender dauerhaft auf der selben Frequenz senden.
Ich mache mir noch ein paar Gedanken und melde mich wieder.
Zum Test könntes Du mal schauen, ob die 433 Mhz Version das selbe Ergebnis bringt
Ich habe gerade die 433-Version getestet.
Da sehe ich mit sharpSDR gar kein Signal auf 868MHz.
So hätte ich das auch erwartet.
Hm, da bleiben jetzt nicht mehr viele Optionen.
Was ich schon mal hatte war, dass ich schlechte USB Kabel hatte und die Spannungsversorgung zusammengebrochen ist.
(das wäre aber nur der Fall wenn Du den CUL über ein schlechtes "Verlängerungskabel" angeschlossen hast.
Die andere Option ist, ich schicke Dir einen nanoCUL der bei mir ebenfalls problemlos funktioniert (habe ihn gerade zusammengelötet, das Ergebnis ist wie bei meinem ProMicroCUL, das Relais hat sofort geschatet, das Signal ist auch da.
Allerdings bin ich nur 1m vom SDR Stick weg.
Die Dose schaltet aber auch noch in 6m Distanz, d.h. dann sollte es bei Dir auch klappten.
Ok, ich werde die nächsten Tage al eine andere USB-Verlängerung probieren.
Gleichzeitig versuche ich den CUL und den SDR näher zusammen zu bringen.
Wenn das bei dir funktioniert, ist es vielleicht doch ein Reichweitenproblem.
Mehr fällt mir im Moment auch nicht dazu ein.
Ich melde mich wieder, wenn ich beide Test's durchgeführt habe.
Erst einmal schönen Sonntag noch für dich .....
Hallo RaspII,
ich habe jetzt einen Test mit einer anderen USB-Verlängerung durchgeführt.
Entfernung zwischen CUL und SDR-Empfänger ca. 7m.
Der Test hat auch nicht funktioniert, das Signal war immer noch extrem schlecht.
Jetzt habe ich ein bisschen umgebaut und den Test wiederholt mit einer Entfernung zwischen CUL und SDR von ca. 1m.
Bei dem Kommando ku6C965A5B25B2DB6DA005000J schaltet der Aktor jetzt auch (entspricht Handsender Taste 1).
Die Entfernung zwischen CUL und Aktor ist auch ca. 1m gewesen.
Ich habe jetzt nacheinander (in einer Datei) die Telegramme vom CUL (1. Telegramm) und vom Handsender (2. Telegramm) aufgezeichnet.
Ich denke in dieser Entfernung sieht die Signalform des CUL-Telegramms wesentlich besser aus.
Was mich wundert ist, das die Sendeleistung des CUL im Vergleich zum Handsender immer noch deutlich niedriger ist.
Gruß
Hi,
ich habe mir das bei mir nochmal angeschaut, da ist alles bestens.
Sender und ProMicroCul sind ca. 5cm auseinander und ca. 1,5m vom Empfänger weg, der ProMicroCUL wird etwas besser empfangen.
Im Anhang siehts Du
1. Sender
2. ProMircoCUL
3. Sender
Amit wir ausschliessen können, dass Dein CUL irgend ein Problem hat, schicke ich Dir mal einen nanoCUL.
Keine Angst, das Porto macht mich nicht arm.
Was mich noch wundert ist, mit welcher Sendebotschaft Du erfolgreich bist.
Nach allem was Du mir bisher an Messdaten geschickt hast müsste diese Botschaft zum Erfolg führen:
6c 96 59 2d 92 d9 6d b6 d8
Aber vermutlich kommen die wesentlichen Bitsequenzen in beiden Blöcken vor.
Hi,
ich habe deine Stick erhalten, vielen Dank.
Leider habe ich heute und morgen wenig Zeit.
Da mir das keine Ruhe gelassen hat, habe ich aber heute einen ersten Schnelltest gemacht.
Seltsamerweise kann ich keine Blöcke senden und empfangen über das CuxD-Terminal.
18:35:31 [ttyUSB0] *** connect(9600:8N1) USB2.0-Serial
Erkannt wurde der Stick schon.
Ich gehe davon aus, dass die Kommandos zum Senden und Empfangen die Gleichen sind.
Am Sonnabend werde ich ausgiebiger testen.
Gruß
Hallo Kanumouse,
gut, das Päckchen ist also unbeschadet angekommen.
Bzgl. Deiner Zeit: Kein Problem, ich habs nicht eilig, Du vermutlich auch nicht, Du hast ja fast 9 Monate darauf gewartet, dass ich überhaupt anfange.
Ich denke das Problem liegt hier:
connect(9600:8N1) USB2.0-Serial
Versuch mal Dich mit 38400 Baud anstelle 9600 mit dem Stick zu verbinden.
Hintergrund (wenn ich mich noch richtig erinnere):
Der CUL hat einen Atmega 32u4, dieser hat ein build in USB Interface, d.h. die Baudrate ist dem CUL letztendlich egal (es passiert keine Wandlung zu seriell).
Der nanoCUL hat einen USB zu RS232 Wandler auf dem Board, da muss die Baudrate der Seriellen Schnittstelle auf dem Atmega328p identisch mit der Baudrate auf dem Raspberry oder CuxD sein.
Hi,
mit einer 38400 Baudrate läuft der Stick jetzt.
Ich habe noch einmal gestestet und die Codes für die Tasten 1 und 2 des Handsenders im Terminal aufgezeichnet.
Der momentane Aufbau beim Test war so, dass der microCUL und der Handsender ca. 2m vom Aktor und der Empfangsantenne des SDR entfernt waren.
Empfangene Codes des Handsenders:
11:20:00 [ttyUSB0] --> kv6C96125B25B2DADB60 - Taste 1
11:20:04 [ttyUSB0] --> kv6C96125B25B2D25B60 - Taste 2
Den Mitschnitt mit dem SDR, sowohl für Taste 1 und 2 des Handsenders, als auch die Auzeichnung für den vom microCUL gesendeten Block ku6C965A5B25B2DB6DA005000J habe ich beigefügt.
Mit diesem Kommando schaltet der Aktor in 95% der Fälle, aber neben nicht immer.
Ich habe das Senden über den microCUL auch mit den beiden vom Handsender empfangenen Blöcken
ku6C96125B25B2DADB6005000J
ku6C96125B25B2D25B6005000J
versucht, aber da ist keine Reaktion am Aktor zu verzeichnen.
Gruß
Hm,
das sieht genauso schrottig aus wie bei Deinem CUL.
Dann können wir zumindest mal sicher sein, dass Dein CUL in Ordnung ist (ist aber nur ein schwacher Trost)
Bei mir Zuhause haben die Signale einwandfrei ausgesehen.
Hast Du eine Möglichkeit den Stick am PC mit einem Terminalprogramm wie z.B. Tera Term zu testen?
Ich habe das Modul bei mir am RasperryPi sowie am PC problemlos am laufen
Hi,
ich habe jetzt den Test am PC mit Putty und dem microCUL durchgeführt und die beiden Blöcke aufgezeichnet.
Abstand zwischen CUL und SDR ca. 1m.
Sieht aus meiner Sicht besser aus.
Der Aktor hat aber beim Senden der Kommandos nicht reagiert.
Im Übrigen hatte ich den CUL vorher an einer CCU3 hängen, aber ich denke, dass hatte ja keinen Einfluß.
Das ist endlich mal ein gutes Signal !!
Was empfängst Du eigentlich wenn Du die Taste 1 am Handsender drückst?
Erwarten würde ich jetzt:
6c96592d92d96db6d8
Wenn Du diesen Code sendest dann sollte das selbe passieren wie wenn Du die Taste 1 am Handsender drückst.
(Die Baudraten stimmen sehr exakt überein)
Bei Taste 1 des Handsenders empfange ich:
kv6C96125B25B2DADB60
wenn ich dieses Kommando sende:
ku6C96125B25B2DADB6005000J
reagiert der Aktor aber nicht.
Schicke mal bitte am nanoCUL folgende Sequenz raus und zeichne das Ergebnis auf:
ku6c96592d92d96db6d805000J
Die Signale waren so sauber, wir müssten das Problem jetzt finden können.
Erledigt, mit dieser Sequenz hat der Aktor (entspricht Taste 1) geschalten.
ok, die Baudrate ist für Deinen Sender etwa 3% zu niedrig eingestellt.
Ich denke die Dose korrigiert das raus, meine Software vermutlich nicht, da ich per Fifo empfange.
Mal sehen ob es mit der angehängten Software besser wird.
Ich habe diese (DRATE) jetzt von 1574,515 (55 FC) auf 1624,10 (56 06) geändert (DRATE Exponent/Mantisse)
Den NanoCUL solltest Du über FHEM flashen können (ich mache das auf der Kommandozeile, dazu müssen aber die AVR Tools installiert sein, via FHEM müsste ich mich erst einlesen). GGf. einfach mit dem CUL am PC versuchen (der müsste auch mit 38400 Baud am PC funktioniern).
Nachtrag:
bin für 30min offline, dann für max. 1h wieder hier
Die Firmware für den CUL hat nicht funktioniert, da er wohl doch nicht mit 38400 Baud arbeiten kann.
Ich habe mit XLoader den nanoCul geflasht.
Zwischen nanoCUL und SDR habe ich ca. 3m.
Mit der Sequenz
ku6c96592d92d96db6d805000J
schaltet der Aktor jetzt jedesmal.
das ist ja schon mal super.
Und was sagt der Empfang (senden geht einfacher ;))
Der Empfang ist auch gut.
Bei jedem Befehl des Handsenders wird die gleich Sequenz empfangen.
und zwar die von oben bei Taste 1?
kv6C96592D92D96DB6D8
Hi,
wenn Du Taste1 drückst würde ich folgendes als Empfang erwarten:
kv6c96592d92d96db6d8(Du hattest nicht dazugeschrieben was Du empfängst).
Im Anhang findest Du eine Tabelle mit allen Kommando's die jetzt funktionieren müssten.
Die Linke Hälfte beschreibt den Handsender bei mir, Dein Handsender müsste arbeiten wie auf der rechten Hälfte beschrieben.
Die "9" als erstes Bytes siehst Du nicht bzw. musst Du nicht eingeben, dass macht meine Software automatisch, da als Syncbyte genutzt.
Wenn das jetzt alles funktinoiert haben wir nur noch ein paar Probleme 8):
- Dein Handsender und mein Handsender sind mit der Baudrate so weit auseinander, dass wir das wir mit der aktuellen Methode nicht beide empfangen können, wie man das löst ist mir klar, nur möchte ich das nicht alles selbst machen. Ich schau mal im Netzt nach, die Routinen dafür (Bits einzeln empfangen und Bitzeiten lernen) gibt es sicher schon. Mit dem Signalduino geht das leider nicht
- Dein CuxD macht in Verbindung mit dem CUL Probleme, aus meiner Sicht gibt es dafür noch folgende möglichkeiten
- Die Spannungsversorgung ist nicht Stabil
- Dein USB Kabel ist zu lang oder hat keine saubre Masse/Versorgungspins (hatte ich schon, am besten ein sehr kurzes Kabel oder ohne Kabel testen)
- Dein CuxD arbeitet auch auf dem CUL und überschreibt uns im lauffenden Betrieb die Konfig
Hab gerade gesehe Du hast mir den ersten Teil oben schon beantwortet, kannst ja trotzdem mal die Excel Tabelle durchtesten
Habe alle Sequenzen des ersten Teils deiner Tabelle bei Drücken der Tasten 0-4 des Handsenders genau so empfangen.
Einen Unterschied bei Taste 1-4 zwischen langem und kurzen Tastendruck ist nicht festzustellen.
Das Senden der Sequenzen funktioniert auch, die Aktoren reagieren.
Deine Hinweise werde ich noch einmal prüfen.
Deinn letzter Hinweis
ZitatDein CuxD arbeitet auch auf dem CUL und überschreibt uns im lauffenden Betrieb die Konfig
kann ich nicht deuten.
In einer halben Stunde muss ich erst einmal offline gehen.
Ich bin morgen abend wieder online.
Ich bin auch für ein paar Stunden weg, aber ich bin mal gespannt ob alle Kommandos wie in der Excel beschrieben bei Dir funktionieren.
Bzgl. unserem Problem mit den Datenraten habe ich hier mal einen neuen Thread eröffnet.
https://forum.fhem.de/index.php/topic,108032.0.html (https://forum.fhem.de/index.php/topic,108032.0.html)
Bzgl:
Zitatein CuxD arbeitet auch auf dem CUL und überschreibt uns im lauffenden Betrieb die Konfig
damit meine ich, ob vielleicht Dein CuxD (oder Deine Homeautomatisierung) den CUL parallel neben dem Terminal nutzt (also z.B. für andere Protokolle einsetzt), oder läuft auf dem CuxD nur noch das Terminalprogramm (ich kenne mich mit diesem Modul überhaupt nicht aus)
beim langen Tastendruck (dauerhaft drücken) sollte nur das letzte Byte unterschiedlich sein, C8 statt D8
Hi,
ich habe noch einmal alles durchgetestet, alle Kommandos funktionieren.
Die Änderung des letzten Bytes bei langem Tastendruck funktioniert auch, hatte ich übersehen, also C8 statt D9.
über den CUl habe ich keine sonstigen Protoolle zu laufen und im CuxD sind keine Geräte definiert, die parallel auf den CUl zugreifen.
Das USB-Kabel habe ich übrigens auch geprüft (mit und ohne USB-Kabel) das gleiche ERgebnis, also kann ich davon ausgehen, dass das Kabel in Ordnung ist.
Eben habe ich auch einen Test mit einem Wandtaster gemacht, den ich in Benutzung habe und damit das Licht an- und ausschalte.
Die Sequenzen des Wandtasters konnte ich nicht empfangen.
Da gehe ich mal davon aus, dass das ebenfalls mit der Baudrate zusammenhängt, das scheint also wirklich hinsichtlich des Empfangs ein Problem zu sein.
Da wir festgestellt haben, dass mein CUL funktioniert, könnte ich dir ja eigenlich den promicroCUL zurücksenden.
Ab nächste Woche (Dienstag) gehe ich nämlich für vier Wochen in den Urlaub.
Ich hab's mit dem Zurüchsenden nicht eilig, von mir aus machen wir das wenn alles funktioniert oder wenn ich dir deine Komponenten zurückschicke (ich kann mir notfalls noch einen zusammenlöten)
Hast du die Tests auch mit deinem
CUL reproduzieren können?
Ja, die Test's habe ich auch mit dem CUL erfolgreich durchgeführt.
Hallo,
gibt es eventuell schon neue Erkenntnisse bzw. Fortschritte?
Nachdem wir festgestellt haben, dass mein CUL in Ordnung ist, habe ich heute deinen CUL an dich per Post zurückgesendet.
Hi,
ja, ich habe die Software inzwischen auf "Slow_RF" portiert.
Ich hatte einige Schwierigkeiten, so langsam glaube ich, dass der CC1101 nicht wirklich optimal für Protokol geeignet ist.
Allerdings funktioniert der Empfang (mehr hab ich noch nicht implementiert) bei mir jetzt sehr zuverlässlich.
Meine Annahme wäre, dass Du damit jetzt alle Deine Fernbedienungen/Schalter reproduzierbar empfangen kannst, da die Bitrate leicht variabel sein kann.
Mal sehen ob das auch der Realität entspricht.
Bzgl. der Vorgehensweise hat sich etwas geändert.
Nach dem Flashen des CULs musst Du erst mal
e
für EE-PROM Factory Reset
und
fx
für slow RF mode eingeben.
und
X21
für EEPROM -> CC1101 eingeben. Das musst Du nur einmal machen.
Danach und nach jedem weiteren Flashen muss man nur noch
X01
zum aktivieren des Empfangsmode eingeben.
Danach sollten nach jedem Tastendruck mehrere Blöcke zu sehen sein, darunter ggf. auch einzelne die nicht identisch sind (diese sind zu ignorieren, filtere ich später per Software raus).
Aber alle Deine Fernbedienungen sollten so reproduzierbare "Blöcke" liefern.
Solltest Du, wie bisher dazwischen senden, musst Du die oben beschriebene Konfiguration (alles ausser der einzelne "e" Befehl) wieder holen damit Du wieder richtig empfangen kannst.
Ich habe Dir mal die Firmware für den CUL übersetzt (hoffentlich keine Fehler dabei gemacht).
Dass Du meine Hardware schon zurückgeschickt hast ist eigentlich schade, da ich für unsere weiteren Tests jetzt wieder für mehrere Targets bauen muss.
Ich bin mir auch nicht 100%ig sicher, ob ich beim Übersetzen vom CUL nicht irgend etwas übersehen habe, aber wir sehen ja was bei Dir passiert.
Dann wünsche ich Dir schon mal viel Erfogl beim Testen
Hallo,
aufgrund der aktuellen Situation bin ich arbeitsmäßig sehr eingebunden und habe wenig Zeit.
Ich habe aber den CUL mit der neuen Firmware geflsht und probiert, bekomme aber keinen Empfang.
Ich weiß nicht, ob es an meiner Vorgehnsweise liegt.
Nach dem Flashen habe ich den Stick an die CCU angeschlossen und in der INI wurden die Befehle e, fx, X21, X01 an den Cul gesendet.
Danach habe ich im Terminal, wie gehabt, krS eingegeben - aber leider kein Empfang zu verzeichnen.
Sicherlich habe ich etwas falsch gemacht?
krS musst Du weglassen, sonst ist der alte Mode wieder aktiv.
nach eingabe des "e" müsste der CUL dauerblinken, d.h. nochmal kurz abziehen und anstecken.
danach sollte es reichen nach jedem Neustart mit
X01
zu initialisieren
Allerdings konnte ich den CUL bei mir nicht testen (nur den nanoCUL), es ist nicht ausgeschlossen, dass ich nicht alle Änderungen übernommen habe.
Bzgl. wenig Zeit:
ich hab damit kein Problem. Wir machen einfach in dem Rythmus weiter, der bei uns beiden passt.
Sollte auch die Slow_RF Methode nicht zum gewünschten Ergebnis führen, würde ich früher oder später aussteigen.
Nachtrag:
Mach am besten den kompletten Vorgang neu, nach Eingabe von "e" wie gesagt den Stick kurz abziehen.
"krS" bitte nicht mehr eingeben, das stellt den Empfangsmode wieder zurück
Nur noch einmal für mich als Fast-Laie zum Verständnis:
Ich flashe den CUL und am Ende nach den Flshen gebe ich das Kommando "dfu-programmer atmega32u4 reset" ein und danach e, oder muss ich den reset-Befehl weglassen?
Erwischt,
keine Ahnung was
dfu-programmer atmega32u4 reset
sein soll.
Programmierst Du den CUL über einen Programmieradapter oder über die FHEM Weboberfläche?
Ich programmiere den CUL unter Windows10 mit folgenden Kommandos:
dfu-programmer.exe atmega32u2 erase --force
dfu-programmer.exe atmega32u2 flash your_firmware.hex
dfu-programmer.exe atmega32u2 reset
Ich denke mal, das letzte Kommando macht einen Restart des Controllers und bringt ihn aus dem programmiermodus.
Insofern müsste ich das natürlich immer machen.
ok
das "e" gibst Du dann im Terminal ein, nehme ich an. Wie gesagt, danach den Stick nochmal abziehen und anstecken.
Hallo,
irgenwie funktioniert das nicht bei mir - ich mache bestimmt etwas falsch.
wenn ich im Terminal fx eingeben will, bekomme ich die Antwort "fx is unknown".
Ich weiß jetzt ert einmal nicht weiter?
Hm, verstehe ich nicht, "fx" müsste gehen.
Es kommt keine Antwort drauf, aber es müsste eine Reaktion kommen.
Wenn Du "e" eintippst fängt der CUL an dauerzublinken, richtig?
Egal wie, bei der Migration von NanoCUL auf CUL habe ich noch ein Fehler gemacht (die Kopp Firmware hatte ich gar nicht aktiviert)
"fx" hätte trotzdem funktionieren müssen, trotzdem hier die korrigierte Version.
Es könnte sein, dass der CUL weniger Speicher hat wie der nanoCUL (ich schau später mal nach) und gar nicht richtig runktioniert.
Poste mal, was auf "?" angezeigt wird.
Hier die korrigierte Version
Hallo,
ich habes jetzt mit der neuen Version probiert - das Ergebnis ist das Gleiche.
"(fx is unknown) Use one of A B C e F G h i K k L l M m N R T t U u V W X x Y Z<\r>"
Ich verstehe auch nicht so richtig, was du mit Dauerblinken meinst.
Wenn ich den Stick mit den Kommandos gelasht habe:
dfu-programmer atmega32u4 erase
dfu-programmer atmega32u4 flash CUL_V3_StandardSlow_RF_Parameter_02.hex
dfu-programmer atmega32u4 reset
blinkt nach dem letzten reset-Kommando der Stick dauerhaft.
Danach gebe ich im Terminalprogramm "e" ein und danach "fx" mit dem Ergebnis von oben.
Nach der Eingabe von "e" müsste dasselbe passieren wie nach dem Flashen (nochmal Dauerblinken).
Wenn ich ein ? im Terminal eingebe, bekomme ich als Ergebnis:
?
? (? is unknown) Use one of A B C E e F f G h i K k l M m R T t U V W X x Y Z z
hier ist das "f" enthalten. "fx" soll den Mode nach SlowRF schalten, das ist der neue Mode den wir benötigen.
Ich schaue mal nach wo das der Unterschied beim CUL/nanoCUL ist.
Du könntest trotzdem nochmal Testen, ob Du nach Eingabe von "X01" etwas von der Ferbedienung empfangen kannst (vermutlich nicht :-( )
Ich melde mich wieder, das kann ja nich so schwer sein.
nachdem ich X01 eingegeben habe kann ich jetzt Blöcke von der FB empfangen:
Beispiel:
k6C96592D92D96D92D8
35 78
35 43
k6C96592D92D96D92D8
43 73
37 43
k6C96592D92D96D92D8
37 78
38 43
k6C96592D92D96D92D8
34 79
39 38
k6C96592D92D96D92D8
Ja wunderbar.
Genau so muss das aussehen.
Ich glaube ich habe das "fx" Problem auch gefunden. Anscheinen ist das so, dass wenn man den "Fast" Mode implementiert hat man den "fx" und danach "X21" benötigt um wieder zurück zu "slowrf" zu kommen. Ich bau später noch eine CUL Version mit fastrf. Ich denke wir benötigen das eigentlich nicht, wir sollten aber "kompatible" Versionen zum testen haben.
Der nächste Schritt wäre, dass Du mal alle Deine Fernbedienungen / Wandschalter testest und schaust ob jetzt plausible Werte kommen.
(Am besten mal alle Tasten drücken und die Ergebnisse hier posten).
Wenn das klappt können wir weitermachen, wenn nicht wirds problematisch, weil das bedeutet würde meine Theorie bzgll Adatieren der Baudrate würde nicht stimmen.
Leider klappt das mit den anderen Fernbedienungen, Tastern nicht.
Da bekomme ich bspw. solche Signale.
Sync1Err
36 79
37 78
36 80
31 78
47 72
40 114
Sync1Err
30 84
35 44
38 83
32 43
38 81
35 39
35 83
34 44
40 79
35 43
35 78
40 43
38 75
40 39
Da haben wir ein Problem.
Die gemessenen Zeiten sehen eigentlich nicht schlecht aus (zumindest manche).
Z.B. direkt nach dem Sync Err.
Ich erwarte zum Synchronisieren zwei Zahlenpaare,
Beim ersten Zahlenpaar muss die zweite Zeit in etwa doppelt so groß sein wie die erste, beim zweiten Zahlenpaar sind beide Zahlen in etwa gleich groß.
Das wäre z.B. bei diesen Zahlenpaaren auch der Fall:
30 84 (da ist die Abweichung schon sehr groß, wird aber noch akzeptiert)
35 44
38 83
32 43
38 81
35 39
35 83
34 44
40 79
35 43
35 78
40 43
38 75
40 39
Wenn danach kein kompletter Block ausgegeben wird, werden nicht genug Bytes/Bits empfangen.
Das kann jetzt dummerweise mehrere Gründe haben.
Ich rechne z.B. damit, das das erste Byte das Längenbyte (09) ist.
Beim zweiten Byte rechne ich damit, dass es immer mit 6 anfäng (also 096.... = 000010010110, wobei ich auf die Bitkombination 10010 Syncronisiere wie oben erwähnt. Sollte Deine andere FB/Taster als zweite Zahl keine 6 senden hätten wir ein Problem.
Hattest Du mir schonmal eine HackRF Messung von dieser FB/Taster zugeschickt?
Dort könnte ich das nachschauen. Wenn ja sollte ich wissen welche Messung das war, wenn nicht solltest Du mir so eine Messung schicken.
Von diesem Taster habe ich dir noch kein HackRF gesendet.
Mache ich fertig!
Hallo,
ich habe jetzt von einem Taster ein HackRF aufgezeichnet.
Hi,
da haben wir den Salat.
Die Botschaften beginnen anders als bei den Handsender -> Mist
Ich muss mal in mich gehen, ich finde gerade keine Möglichkeit mich auf dieses Signal aufzusynchronisieren
Zumindest sind die Anzahl der Bytes identisch, das ist ja schonmal was
Du hattest die Taste mehrmals gedrückt, richtig?
Und beide Anhänge sind identisch oder habe ich da was falsch verstanden
Hi,
das ist ein Doppeltaster (wie ein Zweifach-Lichtschalter), also mit 4 Einzeltastern dahinter.
Ich habe, sozusagen, Taste 1 ein/aus, als auch Taste 2 ein/aus betätigt.
Die Dateien habe ich aus Versehen zweimal angehängt.
Hatte ich Dich schonmal gefragt ob Du noch ein Handbuch oder sonstige Beschreibungen hast von dem System hast?
Ja, aber leider habe ich keine Beschreibung zu diesem System.
So, hatte heute wieder etwas Lust/Zeit.
Ich habe jetzt eine Spezialerkennung eingebaut, d.h. Deine Wandtaster müssten jetzt auch erkannt werden.
Da wir nun wissen, dass das erste Byte (=09) keine Blocklänge war (wie von mir erwartet) gebe ich dieses Byte jetzt zusätzlich aus.
Also nicht wundern, der Handsender bringt jetzt ebenfalls ein Byte mehr.
Da ich weder mit einem CUL noch mit Deinem Wandschalter testen kann, übernehme ich keine Garantie das es auch funktioniert.
Ausserdem wird es einige "Fehlerinterpretationen" der Blöcke geben, macht aber nichts, das filtern wir später weg.
Erwarten würde ich jetzt folgende Blöcke:
b2d96596d96cb6d96d8
b2d96596d96cb6db6d8
b2d96596d96cb6d92d8
b2d96596d96cb6db2d8
Sollte das klappen, dann teste mal bitte was beim jeweiligen "langem Tastendruck" kommt und schicke mir das Ergebnis
Hi,
ich habe jetzt den Test gemacht.
Zuerst mit zwei Tasten der Fernbedienung und dann mit zwei Tasten des Wandtasters.
Mit dem Wandtaster, das scheint noch nicht zu funktionieren.
ok, hab noch einen Fehler beim neuen Sync gefunden.
-> hoffentlich wirds besser.
Das sieht jetzt schon besser aus.
Ich habe den Mitschnitt in zwei Dateien gespeichert, einmal für zwei Tasten der Fernbedienung und einmal für zwei Tasten des Tasters.
Das ist schon mal gar nicht schlecht.
Was ich noch nicht verstehe:
Nach
k0B
müsste es mit
2...
oder
3...
weitergehen, aber nicht mit
1... wie bei Deinen Messungen.
Ich habe die Software mir jetzt zig mal angesehen, dass darf eigentlich gar nicht anders sein, es sei denn es kommt ein viel zu kurzes Bit an.
(Deine SDR Messungen zeigen aber etwas anderes :-)
Ich denke mal bei Gelegenheit darüber nach.
Zitat von: RaspII am 12 April 2020, 12:13:02
Das ist schon mal gar nicht schlecht.
Was ich noch nicht verstehe:
Nach
k0B
müsste es mit
2...
oder
3...
weitergehen, aber nicht mit
1... wie bei Deinen Messungen.
Ich habe die Software mir jetzt zig mal angesehen, dass darf eigentlich gar nicht anders sein, es sei denn es kommt ein viel zu kurzes Bit an.
(Deine SDR Messungen zeigen aber etwas anderes :-)
Ich denke mal bei Gelegenheit darüber nach.
Nachtrag:
kannst Du die Tests mit den Wandschaltern noch einige Male wiederholen?
-> Nur zum sicherstellen, ob der Fehler völlig systematisch ist oder noch manmal die richtige Kombination kommt.
Konnte immer noch keinen Fehler finden. Ich habe Dir mal eine Testversion gebaut, die zu kurze Bitzeiten erkennt. Mal sehen was passiert.
Bei mir kommt das immer mal wieder vor, das liegt extrem wahrscheinlich an den Einstellungen der HF Parameter des CC1101 (mit dem SDR Stick sieht man diesen Effekt nicht).
Hab Dir auch noch eine Oszi-Messung (direkt am CC1101 Pin gemessen) angehängt.
Die markierten Bits müssten alle gleich lang sein, sind sie aber nicht)
Auf dem Oszi sieht das wirklich nicht gut aus!
Ich habe jetzt noch einmal mit deiner neuen Version und dem Taster getestet.
Auf den Taster 3x die Taste 2 und 3x die Taste 1 gedrückt.
Ich kann nicht glauben was ich sehe.
Bei die ist die k0B1... extrem konstant, und das ohne "High-Time nach Sync (zur Kurz!)"
Das kann so eigentlich nicht sein, es muss einen Bug in meiner Software geben.
Ich habe bei mir inzwischen bessere HF Parameter gefunden (trial and Error, mit Theorie komme ich gerade nicht weiter).
Vielleicht kannst Du auch das noch testen.
Was mir bei Deinen Messungen auffällt ist, dass diese viel stabilier laufen als bei mir
Getestet 3x Taste1 und 3x Taste 2 vom Taster betätigt.
Ich denke ich habe das Problem gefunden. 8)
Die Ausgabe der Testinformationen an die Konsole scheinen das Programm um 500usec zu verzögern (habs nachgemessen). Das ist exakt das eine Bit das verloren geht. Ich hätte das nicht erwartet, hatte mir das aber noch nie angeschaut.
Hab nochmal eine Version gebaut (auf die Schnelle), d.h. ich denke jetzt sollte es funktionieren.
Scheint zu funktionieren!
3x Taste 1 und 3x Taste 2 gedrückt.
ok passt.
Das war echt ne schwere Geburt, und scheint recht stabil zu laufen.
Ich räume die SW noch etwas auf und melde mich dann wieder.
(kann etwas dauern)
Ok, awr aber eine tolle Leistung!
Hallo RaspII
geht das Modul auch für die Rolladensteuerung Gen.3
also die Nachfolger vom 8080.02 ?
Hintergrund: Ich will meine 10 Fenster um die fehlenden 2 erweitern
aber die "alten" Gen2 8080.02 gibt es nur noch für "Apothekerpreise".
Gruß Wolfdieter
Hallo Wolfdieter,
leider nein,
Das Protokoll scheint hier wieder komplett geändert zu sein, mir wird das langsam zu zeitintensiv.
Ich werde im lauf des Jahres noch das V1 Protokoll fertigmachen, danach ist erst mal Schluss.
Aber wie der Zufall so will habe ich noch zwei Rolladenmodule (8080.02) hier die ich vermutlich nie benutzen werde.
Wenn Du Interesse hast schick mir ne private Mail mit Deinen Preisvorstellungen (müssen keine Apothekerpreise sein).
Ich kann Dir allerdings nicht viel über den Zustand sagen, ich hatte mir gebrauchte und neue Module gekauft, kann heute nicht mehr sagen welches welche sind.
Viele Grüße
Liebe FHEM- und Kopp-Fans,
ich habe hier viele sehr nützliche Informationen gefunden. Vielen Dank an RaspII, Kanumouse und Papa Felice !!!
Mein nanoCUL-Versuchsaufbau konnte nur von einem meiner Kopp-Wand-Taster Daten empfangen und keine Aktoren schalten (8080.02 Rollladenschalter).
Nach einigen Tests mit der FREQ[0-2]-Einstellung in der ,,kopp-fc.c" bin ich auf den SPI-Trace von ,,Papa Felice"gestoßen. Die Frequenz muss scheinbar sehr genau eingestellt sein.
Freq = 0x2165ca = 2188746 -> 868,33795166 MHz
Damit hat alles sofort funktioniert. Ich habe noch einige andere Kopp-Original-Einstellungen aus dem SPI-Trace übernommen, aber keine Verbesserungen festgestellt. Vielleicht hilft diese Info ja noch jemandem weiter.
Beste Grüße
Hallo Leute,
ich bin nach langer Zeit auch wieder mal am Kopp Interface programmieren.
Allerdings bau ich mir gerade einen Gateway von Kopp 868 auf MQTT über einen ESP8266 und ein CC1101 Funkmodul https://www.amazon.de/-/en/Laqiya-CC1101-Transmission-Antenna-Transceiver/dp/B075PFQ57G (https://www.amazon.de/-/en/Laqiya-CC1101-Transmission-Antenna-Transceiver/dp/B075PFQ57G)
Das ganze soll dann über den Mosquitto Broker in openHAB eingebunden werden.
Hier gibt es in zwischen eine sehr gute Library: ELECHOUSE_CC1101, ein paar Leute haben hier drum auch ein Modul RF_Switch programmiert hauptsächlich für 433 MHz Geräte, Kopp ist da leider nicht dabei.
Ich habe gestern gerade einen Pro Micro mit dem CC1101 Modul zusammengeschlossen und alle Einstellungen für die Kopp Sender eingegeben.
Was ich inzwischen rausgefunden habe ist folgendes:
Kopp sendet auf 868 MHz, allerdings mit einem Channel Spacing von 300kHz und auf Kanal 1 womit sich die 868.3 MHz ergeben.
In der Elechouse Library kann ich folgende Parameter setzen die bei mir am besten funktionieren:
#include <ELECHOUSE_CC1101_SRC_DRV.h>
ELECHOUSE_cc1101.Init(); // must be set to initialize the cc1101!
ELECHOUSE_cc1101.setCCMode(1); // set config for internal transmission mode.
ELECHOUSE_cc1101.setModulation(1); // set modulation mode. 0 = 2-FSK, 1 = GFSK, 2 = ASK/OOK, 3 = 4-FSK, 4 = MSK.
ELECHOUSE_cc1101.setMHZ(868.000); // Here you can set your basic frequency. The lib calculates the frequency automatically (default = 433.92).The cc1101 can: 300-348 MHZ, 387-464MHZ and 779-928MHZ. Read More info from datasheet.
ELECHOUSE_cc1101.setDeviation(47.60); // Set the Frequency deviation in kHz. Value from 1.58 to 380.85. Default is 47.60 kHz.
ELECHOUSE_cc1101.setChannel(1); // Set the Channelnumber from 0 to 255. Default is cahnnel 0.
ELECHOUSE_cc1101.setChsp(300); // The channel spacing is multiplied by the channel number CHAN and added to the base frequency in kHz. Value from 25.39 to 405.45. Default is 199.95 kHz.
ELECHOUSE_cc1101.setRxBW(162.5); // Set the Receive Bandwidth in kHz. Value from 58.03 to 812.50. Default is 812.50 kHz.
ELECHOUSE_cc1101.setDRate(4.785); // Set the Data Rate in kBaud. Value from 0.02 to 1621.83. Default is 99.97 kBaud!
ELECHOUSE_cc1101.setPA(10); // Set TxPower. The following settings are possible depending on the frequency band. (-30 -20 -15 -10 -6 0 5 7 10 11 12) Default is max!
ELECHOUSE_cc1101.setSyncMode(1); // Combined sync-word qualifier mode. 0 = No preamble/sync. 1 = 16 sync word bits detected. 2 = 16/16 sync word bits detected. 3 = 30/32 sync word bits detected. 4 = No preamble/sync, carrier-sense above threshold. 5 = 15/16 + carrier-sense above threshold. 6 = 16/16 + carrier-sense above threshold. 7 = 30/32 + carrier-sense above threshold.
ELECHOUSE_cc1101.setSyncWord(170, 84); // Set sync word. Must be the same for the transmitter and receiver. (Syncword high, Syncword low)
ELECHOUSE_cc1101.setAdrChk(0); // Controls address check configuration of received packages. 0 = No address check. 1 = Address check, no broadcast. 2 = Address check and 0 (0x00) broadcast. 3 = Address check and 0 (0x00) and 255 (0xFF) broadcast.
ELECHOUSE_cc1101.setAddr(0); // Address used for packet filtration. Optional broadcast addresses are 0 (0x00) and 255 (0xFF).
ELECHOUSE_cc1101.setWhiteData(0); // Turn data whitening on / off. 0 = Whitening off. 1 = Whitening on.
ELECHOUSE_cc1101.setPktFormat(0); // Format of RX and TX data. 0 = Normal mode, use FIFOs for RX and TX. 1 = Synchronous serial mode, Data in on GDO0 and data out on either of the GDOx pins. 2 = Random TX mode; sends random data using PN9 generator. Used for test. Works as normal mode, setting 0 (00), in RX. 3 = Asynchronous serial mode, Data in on GDO0 and data out on either of the GDOx pins.
ELECHOUSE_cc1101.setLengthConfig(0); // 0 = Fixed packet length mode. 1 = Variable packet length mode. 2 = Infinite packet length mode. 3 = Reserved
ELECHOUSE_cc1101.setPacketLength(7); // Indicates the packet length when fixed packet length mode is enabled. If variable packet length mode is used, this value indicates the maximum packet length allowed.
ELECHOUSE_cc1101.setCrc(0); // 1 = CRC calculation in TX and CRC check in RX enabled. 0 = CRC disabled for TX and RX.
ELECHOUSE_cc1101.setCRC_AF(0); // Enable automatic flush of RX FIFO when CRC is not OK. This requires that only one packet is in the RXIFIFO and that packet length is limited to the RX FIFO size.
ELECHOUSE_cc1101.setDcFilterOff(0); // Disable digital DC blocking filter before demodulator. Only for data rates ≤ 250 kBaud The recommended IF frequency changes when the DC blocking is disabled. 1 = Disable (current optimized). 0 = Enable (better sensitivity).
ELECHOUSE_cc1101.setManchester(0); // Enables Manchester encoding/decoding. 0 = Disable. 1 = Enable.
ELECHOUSE_cc1101.setFEC(0); // Enable Forward Error Correction (FEC) with interleaving for packet payload (Only supported for fixed packet length mode. 0 = Disable. 1 = Enable.
ELECHOUSE_cc1101.setPQT(4); // Preamble quality estimator threshold. The preamble quality estimator increases an internal counter by one each time a bit is received that is different from the previous bit, and decreases the counter by 8 each time a bit is received that is the same as the last bit. A threshold of 4∙PQT for this counter is used to gate sync word detection. When PQT=0 a sync word is always accepted.
ELECHOUSE_cc1101.setAppendStatus(1); // When enabled, two status bytes will be appended to the payload of the packet. The status bytes contain RSSI and LQI values, as well as CRC OK.
Man kann dann die Datenpakete mit den Codes der Fernsteuerungen einfach über ELECHOUSE_cc1101.ReceiveData(buffer) aus einem Fifo auslesen bzw. mit dem entsprechenden TX Befehlen senden.
Inszwischen kann ich alle Handsender auslesen, da kommen immer 7 Bytes Nutzdaten mit jeweils drei Wiederholungen nach dem Schema:
12,0D,97,74,CC,0F,02 Handsender Schalter auf 5, Taste 8
12,0D,99,65,CC,0F,02 Handsender Schalter auf 5, Taste 7
usw...
Auch das Senden scheint problemlos zu funktionieren, da bin ich grad dran.
Kann Euch gern mehr Infos senden.
Hallo Gemikro, liebes Forum,
interessantes Projekt. Wenn Du noch mehr Informationen über Deine Implementierung geben kannst, würde ich mich freuen.
Ich habe nun zwei Varianten getestet auf dem nanoCUL:
1. culfw -> http://culfw.de/culfw.html
- Mit dem KOPP-FHEM-Modul: https://wiki.fhem.de/wiki/Kopp_Allgemein
2. SIGNALduino -> https://forum.fhem.de/index.php/topic,82379.msg1010643.html#msg1010643 (V 3.3.4-dev200914)
- Mit angepasster Version des KOPP-FHEM-Moduls: https://forum.fhem.de/index.php?action=dlattach;topic=106594.0;attach=132318
Beide Firmware-Versionen funktionieren, jedoch immer noch nicht zuverlässig genug beim Senden. Man muss die Befehle teilweise 3 mal senden, bis der Empfänger (8080.02) sie versteht. Das jedoch nicht immer. Manchmal schalten die Empfänger auch zigmal sofort und richtig. Das Problem ist aber zu jeder Zeit reproduzierbar. Mit den Original-Funk-Tastern funktioniert es immer korrekt.
Ich bin momentan nicht sicher, ob das Problem an den Einstellungen der Parameter im CC1101, in der Aufbereitung der zu sendenden Daten (Counter, Prüfsummen, etc.) oder generell in ungünstigen HF-Bedingungen (Störsender, Antennenanpassung, Leistung) bei mir liegt.
Ich wäre daher sehr interessiert daran, wie Deine Erfahrungen beim Senden sind, wenn das bei Dir implementiert ist.
Viele Grüsse ...
Hallo Haykonus,
ich habe mittlerweile die Befürchtung dass der CC1101 auf den China Modulen sehr schlecht sendet.
Ich hab mir den Output von den Handsendern und dem Modul angesehen und der Vergleich ist eher grauenhaft.
Die CC1100 von den Kopp Schaltern bringen in meinem Testaufbau ca. -15 dB in die Antenne des SDR und die China Module nur ca. -50dB bei gleicher Entfernung.
Wenn man die TX Power voll aufdreht fangen die Dinger an Fehler zu machen, teilweise bricht die Übertragung ganz zusammen.
Ich habe heute die besten Ergebnisse bei 0 dB gemacht, da sieht man wenigstens eine Trennung der FSK Peaks, ansonsten ist das nur ein ziemlicher Matsch.
Das dürfte auch die Ursache für Deine Probleme sein, Du hast das gleiche Modul nach dem Foto.
Ich werd mal versuchen ein paar CC1101 zu bestellen und probeweise eines der Module damit umlöten.
Leider habe ich nur mehr wenige Kopp Empfänger die funktionieren, bei mir sterben die Dinger reihenweise an den Überspannungen der häufigen Gewitter bei uns.
Deswegen steige ich auch um auf Shelly 2.5 für meine Raffstores, da habe ich schon eine eigens compilierte Version von Tasmota drauf laufen.
Die Bastelei mit der Free Control mache ich eher weil ich mich über die Jahre an die Handsender gewöhnt habe.
Mit den 868-er Modulen kann ich die inzwischen perfekt auslesen, das Senden ist wegen dem Problem oben derzeit aber eher nicht zu realisieren.
Was ich in den nächsten Tagen machen werde ist ein Modul aus einem Kopp Wandsender mit meiner Testfirmware zu programmieren und überpürfen ob dort die CC1101 besser gehen.
lg, Gemikro
Hallo Haykonus,
wie viele Windungen hat die Antenne auf dem Steckbrettaufbau auf dem Foto?
Es kommt ab und zu vor, daß eine 433MHz Antenne mit ca 18 Windungen mitgeliefert wird.
Bei den SMA Antennen aus China ist es auch Glücksache was brauchbares zu bekommen.
Gruß Ralf
Hallo Ralf,
das war auch eine meiner ersten Vermutungen, ich habe bei meinem baugleichen Modul auch eine Antenne bekommen mit 18 Windungen.
Hab die aber schon ausgetauscht gegen eine Antenne mit 9 Windungen von einem anderen 868Mhz Gerät aber das ändert an der Performance des China Chips nur wenig.
Bei meinem Modul schwankt die Leistung wenn ich ein identisches Signal mehrmals hintereinander übertrage sehr stark.
Manchmal verliert der Chip überhaupt die Frequenz und sendet ein paar Mhz daneben.
Ich hab heute ein Funkmodul aus einem alten Kopp Rolladenschalter ausgelötet und werd das mal damit vergleichen, zumindest wenn ich den ATmega48 darauf noch zum laufen bringe.
lg Gemikro
ZitatInszwischen kann ich alle Handsender auslesen, da kommen immer 7 Bytes Nutzdaten mit jeweils drei Wiederholungen nach dem Schema:
Das sieht nach dem gleichen Protokoll aus wie es auch im Cul und Signalduino eingebaut ist. Es gibt dafür das Modul 10_KOPP_FC.pm.
Hier ist eine Beispiel Sendenachricht
07FA5E1721CC0F02FE000000000000
sie hat folgenden Aufbau:
07 FA5E 17 21 CC0F 02 FE
07 TRANSMITTERCODE1 $blkctr $keycodehex CC0F TRANSMITTERCODE2 $blkck 000000000000blkctr wird bei jeder gesendeter Nachricht hochgezählt
blkck ist die Prüfsumme
Gruß Ralf
Hallo Gemikro, hallo Ralf9,
@Gemikro: dann kannst du ja mit deinen Messungen bestätigen, was ich hier beobachte. Da bin ich fast erleichtert.
Ich habe hier auch schon viel probiert, um das Problem einzugrenzen:
• Weitere, baugleiche 868 MHz-Module probiert
• Ein anderes 433 MHz Modul mit CC1101 verwendet (mit geringerer Entfernung zum Empfänger)
• Separate 3,3V Spannung (nicht über Arduino) für den CC1101 mit sehr viel Stromreserve und Elkos als Puffer
• Aufbau mit sehr kurzen Drähten zw. Arduino und CC1101-Modul
• Mit/ohne Pegelwandler
• Abstände zw. Sender/Empfänger systematisch variiert
• TX-Power systematisch von -10 dBm ... 10 dBm Leistung variiert
• Antenne mit 18 und 9 Windungen (Danke für den Tipp an Ralf9)
• Und, wie schon gesagt, Firmware ,,culfw" und ,,SIGNALduino" von Ralf9 verwendet
Das Problem zeigte sich immer auf die gleiche Weise, die Empfänger reagieren oft sofort, aber dann doch wieder erst beim zweiten oder dritten Mal Senden.
Ich kann mir das nicht erklären. Wenn natürlich die CC1101-Module bei 868 MHz mit GFSK das Problem sind, müsste man ggf. den CC1150 verwenden, der ein reiner Transmitter ist und in den Original-Kopp-Tastern eingesetzt wird. Meine Schaltung mit dem 868 MHz-Modul funktioniert übrigens sehr gut mit 433 MHz und Somfy-Protokoll. Damit möchte ich meine Heim&Haus-Dachfenster-Rollladen steuern. Dank der tollen SIGNALduino-Firmware von Ralf9, kann man verschiedene CC1101-Register-Konfigurationen speichern und dann leicht zwischen diesen Konfigurationen hin- und herschalten. Ich könnte alles bei mir, außer ein Velux-Fenster :-( , mit einem CC1101-Modul steuern.
Soweit mein ,,Frontbericht". Tolles Forum hier, vielleicht finden wir ja gemeinsam noch eine Lösung.
Viele Grüße,
Haykonus
Hi Haykonus, hi Ralf,
@Haykonus: ich hab in den letzten Tagen viel probiert mit dem Chip, laut SDR hat der deutlich weniger Leistung als die Handsender von Kopp.
Man sieht auch dass die Leistung nochmals sehr stark einbricht wenn man schnell hintereinander den gleichen Befehl absetzt, da dürfte am China Chip etwas im Leistungsteil unterdimensioniert sein.
Für meine Anwendung als reiner Empfänger mit dem ESP8266 reicht es aber bei weitem, das läuft mittlerweile ganz gut.
Ich hab auch noch die Antenne mit den 16 Windungen getestet , da ist zu der mit 9.5 Windungen kaum ein Unterschied.
Wenn ich das richtig rechne passen die aber beide nicht für 868MHz.
Ich hab heute mal eine Ringantenne mit richtiger Länge drauf gelötet, ähnlich zu der in den Kopp Empfängern, die geht etwas besser.
Ausserdem sind die Frequenzabweichungen zwischen den China Prints gewaltig, ich habe inzwischen drei davon getestet und die waren zwischen 50 und 100kHz daneben.
Die Library die ich verwende hat wenigestens eine Funktion dass man die Frequenz mit dem SDR als Feedback kalibrieren kann.
Ich hab ein paar Prints aus den Kopp Rollladenschaltern ausgebaut und in Betrieb genommen.
Leider hat der ATmega48 aber etwas wenig Flash und ich habe bisher den CC1100 darauf noch nicht zum Laufen bekommen weil der Ouptut des Arduino Compilers noch zu groß ist.
Hi Haykonius,
mit der neuen Antenne habe ich jetzt auch den Sender zum Laufen gebracht.
Ich habe auch einen 8080.02 Rolladenschalter zerlegt und mir den SPI Startup angesehen (Power on Codes.txt).
Ist minimal anders als beim Listing von Papa Felice, hauptsächlich die Kalibrationswerte.
Ich hab Dir auch den Arduino Code angehängt, der schaltet bei mir jetzt zuverlässig, ich verwende übrigens einen Pro Micro 3.3V / 16 MHz.
Grüsse, Gemikro
Hallo Gemikro,
ich kann es noch nicht glauben – mit Deinem Code funktioniert es tatsächlich richtig zuverlässig. Der 8080.02 schaltet nun wirklich jedes Mal. Super !!! Es hat hier bei mir nichts mit der Antenne, Hardware, etc. zu tun. Das hatte ich auch schon vermutet, da ich ja so extrem viel an den Hardwareparametern geändert hatte und sich das Problem trotzdem immer exakt gleich zeigte.
Jetzt würde ich wirklich einmal wissen wollen, ob es an den angepassten Kalibrationswerten aus Deinem SPI-Trace liegt. Man müsste das doch auch mit ,,culfw" oder besser noch mit ,,SIGNALduino" hinbekommen. Ich werde das noch einmal probieren. Aber wenn es nicht gehen sollte, baue ich das auch selbst mit der ELECHOUSE Library.
Vielen Dank hier an Alle im Forum – das macht wirklich Spaß !
Viele Grüße,
Haykonus
Ich hab mal die cc1101 Register vom Signalduino mit denen vom Gemikro verglichen, da sind einige Werte anders.
Ich kann aber nicht abschätzen welche entscheidend sind.
Ich hab die sduino Register vor den Registern von Gemikro eingefügt:
sduino
0x01 IOCFG1 0B -> GDO1 serial clock
0x02 IOCFG0 0C -> GDO0 serial synchronous data output
0x06 PKTLEN 0F FF -> max length 255
0x07 PKTCTRL1 E0 00 -> no address check, no status append, no crc autoflush, Preamble quality threshold 0
0x08 PKTCTRL2 00 12 -> variable length, synchronous serial mode with data in GDO0
0x09 ADDR *00 00 -> no addr
0x0B FSCTLR1 06 06 -> Freq_if = 152.34375kHz
0x0C FSCTRL0 *00 00 -> FreqOffset = 0
0x0D FREQ0 21 21 ->
0x0E FREQ1 65 65 ->|->
0x0F FREQ0 6A E1 ->|->|-> Freq = 868,347076 MHz
0x10 MDMCFG4 97 C7 -> BW_Chan = 101.5625 kHz
0x11 MDMCFG3 83 83 -> DataRate = 4797.935 Hz
0x12 MDMCFG2 16 10 -> No Preamble !, No Manch., GFSK, Enable DC Filter
0x13 MDMCFG1 63 22 -> 4 Preamble Bytes (but disabled !), FEC disabled
0x14 MDMCFG0 B9 F8 -> Channel Spacing = 199.951 kHz
0x0A CHANNR 00 00 -> Channel 0
0x15 DEVIATN 47 40 -> FreqDev = 25.390 kHz
0x21 FREND1 *56 56 -> Default Value (LNA, Buffer, Mixer Currents)
0x22 FREND0 11 10 -> Default Value (PA Power Table)
0x18 MCSM0 29 08 -> Osc. Setup Time 150µs, no fs_autocal
0x19 FOCCFG 36 12 -> Frq. Comp Gain 3K, no offset compensation
0x1A BSCFG *6C 6C -> no rate offset, Post: Kp, Ki/2, Pre: 3Kp, 2Ki
0x1B AGCCTRL2 07 43 -> Target 33dB, Max pos. LNA Gain, highest gain set. not used
0x1D AGCCTRL0 91 91 -> 16 samples, no AGC freeze, wait time 16 samples, low hyst.
0x23 FSCAL3 00 E9 -> calib value from SmartRF Studio
0x24 FSCAL2 2A 2A ->
0x25 FSCAL1 00 ??
0x26 FSCAL0 11 1F ->
* = default
Hier ist eine Beispiel Sendenachricht vom sduino
07FA5E1721CC0F02FE000000000000
Mich würde interessieren wie eine Sendenachricht von Gemikro aussieht.
Gruß Ralf
Hallo Ralf,
eine Nachricht sieht z.B. so aus:
00:21:52.169 -> AA,AA,AA,AA,AA,AA,AA,AA,AA,AA,AA,AA,AA,AA,AA,54,07,63,88,6B,10,CC,0F,03,FD,00,4F
Grüße,
Haykonus
Hallo Gemikro, hallo Ralf,
ich habe noch einige Versuche gemacht.
Durch schrittweises Verringern der Anzahl der Sync-Bytes ,AA' konnte ich quasi den schlechten Empfang simulieren. Ab ca. 6 x ,AA' funktioniert der Empfang immer schlechter und dann gar nicht mehr. Die Anzahl der Paket-Wiederholungen bei Gemikro war 4.
Ich habe nun die Gesamtdauer des HF-Signals eines Tastendrucks der Originalschalter gemessen und mit der Dauer meiner gesendeten ,,Tastendrücke" verglichen.
Da wir wissen, dass die Originalschalter die Pakete 13 Mal hintereinander senden, konnte ich durch Einstellen der Anzahl der Sync-Bytes ,AA' und der gleichen Anzahl an Paket-Wiederholungen (13), die gleiche Länge eines Tastendrucks im Vergleich zu den Originalschaltern einstellen.
Das Ergebnis ist folgender Paketaufbau:
13:44:33.460 -> Sending...
13:44:33.460 -> AA,AA,AA,AA,AA,AA,AA,AA,AA,AA,AA,AA,AA,AA,AA,AA,AA,AA,AA,AA,AA,AA,AA,AA,54,07,63,88,01,10,CC,0F,03,97,00,
13:44:34.308 -> Sent !
Ich musste die Anzahl der Sync-Bytes ,AA' von 16 auf 24 erhöhen, um auf die Gesamt-Sende-Dauer der Originalschalter zu kommen. Das funktioniert nun ultra-sicher. Im Originalcode von Gemikro wurde am Ende noch das Byte ,4F' angezeigt, jedoch nicht gesendet. Das spielt also keine Rolle.
@Ralf: Könnten diese Informationen helfen, den Code im SIGNALduino anzupassen ? Ich habe noch gar nicht geschaut, wie das dort mit den Sync-Bytes ,AA' gemacht wird. Vielleicht wäre das schon die Lösung.
Viele Grüße,
Haykonus
Beim cul und sduino werden momentan durch das Register 0x13 MDMCFG1 mit 0x63 16 Preamble gesendet, mit 0x73 werden 24 Preamble gesendet.
Momentan werden bei der für den Signalduino angepassten 10_KOPP_FC.pm am Ende noch einige 00 angehängt
07FA5E1721CC0F02FE000000000000
damit nur eine 00 angehängt wird, muss noch in der 10_KOPP_FC.pm diese Zeile angepasst werden:
sub KOPP_FC_SendCommand($@)
$message = "SN;R=13;N=4;D=" . $dmsg . sprintf("%02x",$blkck) . "00;"; # alt "000000000000;"
neu 07FA5E1721CC0F02FE00
Vielleicht reicht es, wenn bei den sduino cc1101 registern die folgenden 6 Register angepasst werden
Reg
00 01
01 2E
02 46
03 04 FIFOTHR
04 AA SYNC1
05 54 SYNC0
06 0F PKTLEN 0F = 15 Bytes -> neu FF = max length 255
07 E0 PKTCTRL1
08 00 PKTCTRL0 00 = Fixed package length -> neu 01 = variable length
0D 21 FREQ2
0E 65 FREQ1
0F 6A FREQ0
10 97 MDMCFG4 97 = bWidth 162,5 -> neu C7 = 101.5625 kHz
11 83 MDMCFG3
12 16 MDMCFG2
13 63 MDMCFG1 63 = 16 Preamble -> neu 73 = 24 Preamble
14 B9 MDMCFG0 B9 = Channel spacing 350kHz -> neu F8 = 199.951 kHz
15 47 DEVIATN 47 = 47,607 khz (default) -> neu 40 = 25.390 kHz
17 0C MCSM1
18 29 MCSM0
19 36 FOCCFG
1B 07 AGCCTRL2
1C 40 AGCCTRL1
1D 91 AGCCTRL0
22 11 FREND0
23 E9 FSCAL3
24 2A FSCAL2
25 00 FSCAL1
26 11 FSCAL0
Gruß Ralf
Hallo Ralf, hallo Gemikro,
ich habe nun folgende Konfiguration, die bei mir auch mit dem SIGNALduino sehr gut funktioniert (s.Code).
MDMCFG4, MDMCFG0, DEVIATN hatte ich auch schon genau so angepasst - zusammen mit MDMCFG1=73 (24 Preamble) läuft es jetzt richtig stabil.
Jetzt kann ich die "Heim&Haus"- und "KOPP"-Rollladen alle mit einem CC1101 am SIGNALduino steuern. Coole Sache ...
Vielen Dank für Eure Hilfe !
Grüße,
Haykonus
Reg Haykonus
00 01
01 2E
02 46
03 04 FIFOTHR
04 AA SYNC1
05 54 SYNC0
06 0F PKTLEN
07 E0 PKTCTRL1
08 00 PKTCTRL0
0D 21 FREQ2
0E 65 FREQ1
0F CA* FREQ0 6A = 868,299 MHz -> neu CA = 868,338 MHz
10 C7* MDMCFG4 97 = bWidth 162,5 -> neu C7 = 101.5625 kHz
11 83 MDMCFG3
12 16 MDMCFG2
13 73* MDMCFG1 63 = 16 Preamble -> neu 73 = 24 Preamble
14 F8* MDMCFG0 B9 = Channel spacing 350kHz -> neu F8 = 199.951 kHz
15 40* DEVIATN 47 = 47,607 khz (default) -> neu 40 = 25.390 kHz
16 07 MCSM2
17 0C MCSM1
18 29 MCSM0
19 36 FOCCFG
1B 07 AGCCTRL2
1C 40 AGCCTRL1
1D 91 AGCCTRL0
22 11 FREND0
23 E9 FSCAL3
24 2A FSCAL2
25 00 FSCAL1
26 1F* FSCAL0 11 = fscal0 alt -> neu 1F = fscal0 neu
Hast Du auch die Anpassung in der 10_KOPP_FC.pm (nur noch eine 00 am Ende) vorgenommen?
Hat sich am Empfang der Fernbedienung was geändert?
Gruß Ralf
Hallo Ralf,
die 10_KOPP_FC.pm hatte ich als erstes angepasst, aber da gibt es keinen Unterschied. Ich habe es aber jetzt so gelassen, d.h. es wird nur einmal 00 gesendet.
Die Handsender funktionieren weiterhin. Der Rolling Code spielt bei KOPP scheinbar keine Rolle - zumindest bei den 8080.02-Empfängern nicht.
Viele Grüße,
Haykonus
Hallo Ralf, hallo Haykonus,
sorry Leute, ich war etwas angehängt in der Firma in den letzten Tagen.
Was ich gemacht habe ist einen Trace von der Initialisierung der Kopp Schaltern und Taster anzusehen (Saleae Logic Analysator), kann ich auch hier reinhängen wenn ihr den braucht aber das meiste steht schon in der Text Datei.
Die Schalter sind leicht anders konfiguriert als die Empfänger aber das sollte sich auf den Arduino Code nicht auswirken.
Ich habe mit einer Version des Programms mehrere Telegramme aufgezeichnet, das Problem der Library war dass wegen der von Kopp angegeben Länge von 7 Zeichen den CRC und die davor gesendeten Preambel nicht angezeigt hat.
Kopp verwendet nur sehr wenige Funktionen von CC1100/1101, praktisch alles was die Überprüfung der Message betrifft ist deaktiviert z.b der eingebaute CRC, Preamble, Manchester und FEC sind alles aus.
Deswegen war meine Vermutung dass der Sender alle Bytes der Message samt Preamble, Länge und das eine Byte CRC einfach berechnet, als String zusammenstellt und ca. 4-5 mal hintereinander wiederholt sendet.
Das habe ich dann ins Programm eingebaut und das funktioniert sehr gut.
Der Tastendruckzähler hat wahrscheinlich damit zu tun dass der CC1100 die Wiederholungen empfängt und puffert und dann der Schalter eventuell zweimal schalten würde.
Soweit ich das aus dem Atmel Code sehe werden einfach alle eingehenden Nachrichten mit dem gleichen Code bearbeitet und nur ein Schaltereignis ausgelöst wenn sich der Zählerwert ändert.
Die Preambel Bytes werden ebenfalls händisch eingebaut, in den Setup Befehlen für den Sender ist ja die Preamble Länge auf Null gesetzt.
Grüsse, Gemikro
Übrigens:
Die Kalibrationswerte sind tatsächlich recht wichtig, vorallem bei den China Chips.
Ich muß bei meinem Testaufbau jeden Sender extra kalibrieren (ich verwende hier SDR Sharp oder den TinySA).
Es gibt hier eine Software von TI (Smart RF Studio) über den sich der CC1101 einstellen lässt und das die Registerwerte ausspuckt.
Über die Elechouse Library geht das auch (https://github.com/LSatan/CC1101-Debug-Service-Tool (https://github.com/LSatan/CC1101-Debug-Service-Tool)
Ich habe den Code von LSatan nur etwas angepasst an die SPI Pins vom ProMicro und dann für jeden CC1101 mit dem SDR die passenden Werte ermittelt.
Es gibt auch ein sehr gutes und kleines CC1101 Modul mit Antennenstecker von Anaren A1101R04C-EZ4E (z.b. bei Farnell, Digikey) da habe ich jetzt welche bestellt.
Das wäre wahrscheinlich für euren Nano CUL gut brauchbar als Huckepack Modul.
lg Gemikro