FB Betty in FHEM einbinden

[KölnSolar]

Hallo Christoph,
danke 
Ich hab sie ja mit jeweils einer Sendediode ersetzt. Nur der IR-Empfang geht jetzt nicht mehr. Nicht sooo dramatisch, da ich jetzt ja alle meine IR-Geräte u. Intertechno laufen hab. 
Vollendet ? Nicht ganz. Nur ein Etappensieg. Jetzt geht's weiter mit culfw FS20-Senden und Empfang....
Grüße Markus

[KölnSolar]

so, nun funktioniert auch das OOK-Senden mit 868 MHz. Exemplarisch für FS20 eingebaut und erfolgreich getestet. Die letzte Hürde wurde hier gemeistert.

Die Sendeleistung ist erwartungsgemäß sehr mäßig. Möglicherweise durch Anpassungen an der PA table aber noch verbesserbar.

Sendetechnisch können wir nun also das, was eine Kombi-Multi-FB können sollte: OOK-Funk mit 433 u. 868MHz, IR für ALLE(denke ich) Frequenzen und Protokolle.

Jetzt aber ran an den Empfang.....
Grüße Markus

[KölnSolar]

Yippih 
Die Betty empfängt SlowRF-Protokolle. MEINE gibt jetzt Töne von sich, wenn es an der Haustür klingelt, jemand durch den Garten läuft......

Die Basis ist somit geschaffen neben den bisherigen FB-Funktionalitäten(IR u. SlowRF) eine "echte" FHEM-Anbindung zu schaffen. Mitstreiter und Ideen willkommen 

Neben fest codierten Aktionen(also "starre" und fest verdrahtete Aktionen aufgrund von z.B. "normalem" on-/off-IT-code)  könnte man u.U. ein FHEM Modul entwerfen, mit welchem man Parameter der Aktion flexibel parametrieren kann(z.B. Frequenzen v. Alarmtönen, Tonpausen, Wiederholungen, LCD-Nachrichten....) Dabei könnte man das FHEM-Modul einfach nur als "Codiertool" "missbrauchen" und die Kodierung dann im Flash speichern oder jede Message individuell senden.  Jemand ne Meinung, Lust ?

@Telekatz: Ich bräuchte aber wieder mal Deine Hilfestellung. Ich habe den Empfang unschön über GDO0 als GPIO umgesetzt. Müsste also das Ganze über die Main-Loop laufen lassen. Leider bekomme ich den EINT0 partout nicht zum rennen, um das zu vermeiden.  Beim CUL wird ja der EINT auf rising&falling edges eingestellt. Beim LPC2220 geht das aber nicht. Folglich habe ich ihn auf edge sensitive eingestellt und versuche bei jedem Interrupt von rising auf falling edge  und umgekehrt zu wechseln. Es wird aber never ever die interrupt routine aufgerufen  Die CC1100-Mimik funktioniert, sonst bekäm ich ja keine Daten bei Nutzung des Pins als GPIO. Ich füge mal die entscheidenden Codepassagen ein, vielleicht siehst Du oder jemand anders meinen Fehler 

Code Auswählen Erweitern



startRFIRQ(false);


void startRFIRQ(unsigned char mode) {

stopRFIRQ();

EXTINT |= (1<<0);

PINSEL1 |= (1<<0); //GDO0 as EINT0
EXTMODE |= (1<<0); //edge sensitive
EXTWAKE |= (1<<0);


if(sync) {
EXTPOLAR &= ~(1<<0); //falling edge
VICVectAddr2 = (unsigned long)&(cc1100IRQ);
}
else {
EXTPOLAR |=(1<<0); //rising  edge sensitive
VICVectAddr2 = (unsigned long)&(RFasyncmode_ISR);
}

VICVectCntl2 = VIC_SLOT_EN | INT_SRC_EINT0;
VICIntEnable = INT_EINT0;
}

void RFasyncmode_ISR(void) {

stopRFIRQ();
VICSoftIntClr = INT_EINT0; //notwendig ?

rf_receive_IN_PIN(); // entspricht culfw ISR(CC1100_INTVECT)
draw_string(5, 60, "eint0", LCD_COLOR_B, DRAW_PUT);

EXTINT |= (1<<0);
if (!(EXTPOLAR & 0x01)) EXTPOLAR |= (1<<0); //rising  edge sensitive
else EXTPOLAR &= ~(1<<0); //falling edge sensitive

VICIntEnable = INT_EINT0;
}



Jetzt muss ich ans Tuning, um die Erkennungsrate(Reichweite) noch zu verbessern....

PS: Dank eines edlen Spenders hab ich nun auch wieder 2 "Original-Bettys" 

[Telekatz]

Anhand der Codepassage konnte ich jetzt keinen Fehler finden. Kannst du mal deinen kompletten Änderungen am Sourcecode veröffentlichen.

[KölnSolar]

Au Mann 
Wie ich alle Änderungen einstellen soll hat mich überfordert  Also hab ich versucht so weit wie möglich zu reduzieren u. hab neue Debugmeldungen eingebaut. Und dann fiel es mir wie Schuppen von den Augen: die startRFIRQ(unsigned char mode) rufe ich mit false auf. ABER: anstatt auch mode für die beiden Zweige abzufragen, habe ich sync(eine Konstate) auf wahr geprüft u. folglich hab ich immer den Vector auf die cc1100IRQ gesetzt 

Danke für den Denkanstoß. Mal schauen, ob das nun mit dem switch der r-/f-edges klappt....

[Telekatz]

Wie ich alle Änderungen einstellen soll hat mich überfordert

Pack den Ordner boop/trunk in ein Archiv und lade es hoch.

[KölnSolar]

Hi Telekatz,
schon klar. Will aber das Forum nicht zumüllen mit Entwicklungen im Entwicklungsstadium. Jetzt muss ich erst einmal konzeptionelle Entscheidungen treffen. Bisher wird ja im Hintergrund sporadisch synchron empfangen. Wenn ich es richtig sehe, nur für die Zeit-Datumseinstellung, sofern an einer anderen Betty gerade geändert oder Testfunktionen. Mit voller CUL-Funktion geht das nicht mehr. Beraubt Boop aber auch nicht einer wesentlichen Funktion. Ich plane daher synchron so lange zu erhalten, bis die neue IR_CUL aufgerufen wird. Synchron wird dann nur noch im settings-clock-menu u. Testmenü unterstützt. Ob ich mir mit der Verwendung des timer1 f. den CUL ein Ei ins Nest gelegt habe, wage ich auch noch nicht zu beurteilen. Strom sparen u. Reichweite muss auch noch verbessert werden. Noch viel Arbeit vor einer Veröffentlichung.

Ich wollte mich danach in das github der aculfw integrieren. Dazu werde ich Kontakt zu Björn aufnehmen.

PS: Eint0 u. polarity-change funktioniert prinzipiell. Irgendwas schaltet aber noch periodisch u. temporär den Empfang ab. nNur was u. wo 

[Telekatz]

Ich denke nicht, dass man aus der Betty ein CUL Gerät machen sollte. Deshalb denke ich auch nicht, dass es sinnvoll ist, den Code in die aculfw zu integrieren. Die gemeinsame Codebasis ist dafür zu gering. Die Betty Firmware sollte in einem separaten Repository bleiben.

[Telekatz]

Ich hab jetzt auch mal etwas an der Boop Firmware gearbeitet. Die IR Encoder sind jetzt alle auf Hardware PWM umgebaut worden. Auch das B&O Protokoll sah am Oszi brauchbar aus.

Die RF Parameter habe ich für die Kommunikation mit einem CUL etwas angepasst. Für die entsprechenden Modifikationen zum Empfang der Betty mit der a-culfw haben ich einen neuen Branch erstellt.
Aktiviert und getestet habe ich das neue Protokoll mit dem MapleCUN und dem CUBe. Beim nanoCUL habe ich das Betty Protokoll auch eingebaut, aber mangels Hardware nicht getestet. Wer es ausprobieren möchte, muss sich die Firmware selber compilieren.

Für die Kommunikation mit FHEM habe ich eine angepasste Version von 00_CUL.pm und einneues Modul 10_Betty.pm erstellt. Damit funktioniert aktuell das Senden der Uhrzeit an die Betty und der Empfang der beiden RF IR Encoder.

Für Boop habe ich auf Github ein neues Repository erstellt: https://github.com/Telekatz/boop
Dort sind auch die beiden FHEM Module enthalten.

[KölnSolar]

Hmmm, jetzt haben wir 2 verschiedene Ansätze. Ich wollte ja mehr die aculfw-Funktionalität in Boop integrieren. Kommunikation mit FHEM als RFR_CUL. Also quasi ein CUL ohne USB mit FB-Funktionalität von boop.

Du hast jetzt ein "neues" Protokoll und einen neuen rfmode für den CUL geschaffen, was doch wiederum bedeutet, dass ein separater CUL benötigt wird, keine aculfw-Sende-/Empfangsmöglichkeiten, kein RFR,....vorhanden sind. Jedes neu zu implementierende Funkprotokoll muss neu entwickelt u. implementiert werden. Einzigen Vorteil den ich sehe, dass die ursprüngliche Struktur(RF synchron/asynchron) erhalten bleibt. Da die aber mit wenig Funktionalität daherkommt......

Vielleicht sehe ich gerade aber nur nicht den wahren Sinn 

B&O geht mit der .bin nicht. Vielleicht nur eine "veraltete" beo4 von mir ? Hast Du auch die Besonderheit des Protokolls berücksichtigt, dass es das sogenannte repeat-bit gibt ? Wird immer dann f. das Folgebit genutzt, wenn das Folgebit gleich dem vorherigen ist. Spacepulslänge ist die doppelte Spacepulslänge des Nullbits.

Muss jetzt erst mal gucken, wie ich die neue Source kompiliert bekomme, den Betty-Branch einrichten, die Anpassungen für den CUL machen und schließlich die aculfw-branch-betty kompilieren u. flashen. Toolchain f. den CUL ist auf nem verliehenen Rpi 

Edit: Mit meiner beo4 geht es auch nicht und den repeat-bit part von mir hast Du ja auch drin. Ich kann mich schwach daran erinnern, dass mir irgendwelche Berechnungen der cycles oder etwas anderes , wo eine Mehrfachoperation stattfand, Probleme bereitet hat. Ich hänge mal meine ir_lirc, die beo4 u. auch die dbox2 u. die samsung_ue46b6000, wo ich jeweils geringfügig Tastencommands korrigiert hatte, an.
Und irgendwie macht die Tastatur seltsame Dinge  Muss die keyboard.h wieder geändert werden ?

[Telekatz]

Eine Anbindung an FHEM mit dem RFR Protokoll halte ich einfach für nicht praktikabel. Um das Ping, das über SlowRF vom CUL gesendet wird zu empfangen, muss der CC1100 ständig auf Empfang geschaltet sein und der µC würde auch ständig laufen, um das empfangene Signal zu decodieren. Die Batterielaufzeit der Betty ist so schon nicht berauschend und würde dadurch noch geringer. Und deshalb ist meiner Meinung nach die Betty als CUL artiger Empfänger ungeeignet.

Mit meiner Implementierung läuft der CC1100 im WOR Modus und ist nur während kurzer Intervalle im Empfangsmodus. Den Rest der Zeit legt er sich schlafen. Und erst, wenn der CC1100 ein gültiges Paket empfangen hat, wird der µC zur weiteren Bearbeitung aufgeweckt. Damit ist eine bidirektionale Kommunikation zwischen FHEM und Betty möglich und einer Implementierung der Sendemöglichkeiten aus der aculfw wird dadurch auch nicht behindert.

Für B&O habe ich die Informationen als Basis gehabt, die du hier vor längerer Zeit gepostet hattest. An das Repeat Bit habe ich auch gedacht, siehe Bild im Anhang. Ich hätte es ja gerne mit deiner aktuellen Implementierung verglichen, aber dafür fehlten mir die Sourcen.

Zum kompilieren der Betty Sourcen solltest du maximal die Version 4.8 der Launchpad Toolchain verwenden. 

[KölnSolar]

Mein Edit im vorherigen Post hattest Du gesehen ?

Ja stimmt. Und nicht nur für den Ping, sondern auch für empfangene u. an den "stationären" CUL weiterzuleitende Pakete. Und ja, die Bat.Laufzeit geht rapide nach unten. Da die aber eh nicht berauschend ist, ist es egal, ob die Dame 2mal am Tag oder alle 2 Tage in die Station muss. Um an anderer Stelle etwas zu sparen, hab ich unbenötigte Peripherie abgeschaltet. Neue und stärkere Akkus würden sicherlich zu 24h Laufzeit führen.
Aber ein weiteres Manko des RFR ist, dass nicht alle Protokolle funktionieren  z.B IT  Aber da baue ich noch auf eine Änderung.
Ich find halt die Idee der Reichweitenverlängerung schön 
Und die bisherigen Entwicklungen(Lernen ) möchte ich ja für den Scart-Adapter übernehmen. Aber hey, wie wäre es mit der Kombi ? Scart-Adapter als RFR für den der es mag und der gibt Empfangenes an die Betty in bekannter Weise weiter. Apropos bekannte Weise: das rf send über FHEM ist dann ja logischerweise zeitverzögert, oder ?

Aber seis drum, den RFR-mode könnte ich ja nur für mich separat entwickeln, wenn wir die aculfw wenigstens zum senden integrieren. Ich schick Dir mal ne PN damit ich Dir meinen Entwicklungsstand bzgl. aculfw-slowrf schicken und Du Dir z.B die ir_cul angucken kannst. 

Wie sieht denn ein raw Befehl mit 10_Betty aus ?

Zum kompilieren der Betty Sourcen solltest du maximal die Version 4.8 der Launchpad Toolchain verwenden. 

Hab das installiert, was Du damals empfohlen hattest. (was auch immer das war, aber es funktioniert ja)

[Telekatz]

Für die Reichweitenverlängerung ohne Kabel gibt es bessere Lösungen, z.B ein ESP8266.

In der Richtung FHEM zu Betty gibt es eine Verzögerung von etwa 0,5 Sekunden, da erst mal ein WOR Paket zum wecken der Betty gesendet werden muss.

Der raw Befehl für 10_Betty sieht eigentlich fast genauso aus wie einer für 00_CUL, mit der Ausnahme, dass das "y" Prefix für das Betty Protokoll automatisch vorangestellt wird.

WOR Packet:

Code Auswählen Erweitern

w00

Zeit Setzen:

Code Auswählen Erweitern


s0a01000322060717081000


Zum Aufbau der Daten solltest du mal in cc1100/rf.h und cc1100/rf.c schauen.

[Per]

Ich verstehe zwar nur etwa 10 % von dem, was ihr euch hier an Stichworten zuruft (z.B. "Betty" ), aber ich bin ganz zuversichtlich, dass ihr der alten Dame ein ganz neues Leben verpasst!

[KölnSolar]

Ja, sorry. Von grober Funktionsdiskussion rutscht man bei der Entwicklung schnell in die nicht mehr allgemein verständlichen Tiefen der Details ab.

Aber mach doch schon mal einen Anfang, leg Dir einen Adapter zum flashen zu. Dann kannst Du die ersten Lebenszeichen schon ausprobieren 

Welche neuen Organe würden Dir denn Freude bereiten ?

Für die Reichweitenverlängerung ohne Kabel gibt es bessere Lösungen, z.B ein ESP8266.

Bestimmt. aber ich hab mich doch so in die Betty verguckt  Hab mir gerade nochmal die Speichermöglichkeiten angesehen. 64k beim SCART-Interface. Übel. Also wenn überhaupt max. ein Protokoll  Aber wegschmeißen ? Niemals !