Einbindung der kostengünstigen Funkschaltsteckdose PCA 301 mit Energiemessung

[ohweh]

Hmm, das mit 212g hab ich gerade schon probiert, da kommt das hier bei raus (mit n=20):

 ? 1 7 248 71 1 170 170 170 0 0 0 0 0 0 0 0 0 0 0 0 0
 ? 1 7 248 71 0 170 170 170 0 0 0 0 0 0 0 0 0 0 0 0 0
 ? 1 7 248 71 1 170 170 170 0 0 0 0 0 0 0 0 0 0 0 0 0
 ? 1 7 248 71 1 170 170 170 0 0 0 0 0 0 0 0 0 0 0 0 0
 ? 1 7 248 71 0 170 170 170 0 0 0 0 0 0 0 0 0 0 0 0 0
 ? 1 7 248 71 0 170 170 170 0 0 0 0 0 0 0 0 0 0 0 0 0

Also die Preabmle-Bytes sind jetzt enthalten, aber der Rest ist 0.

Mit 0g krieg ich das hier:

 ? G212 128 253 187 122 112 221 224 69 61 241 89 181 203 141 199 245 254 16 37 21 208
 ? G212 1 7 248 71 1 170 170 170 228 239 126 127 129 0 49 143 62 156 24 69 65
 ? G212 1 7 248 71 1 170 170 170 241 250 89 123 124 112 18 28 210 73 144 77 155
 ? G212 1 7 248 71 0 170 170 170 191 239 20 247 56 51 138 234 168 202 36 209 187
 ? G212 1 7 248 71 1 170 170 170 191 239 20 247 56 51 138 234 168 202 36 209 187
 ? G212 1 7 248 71 0 170 170 170 51 142 21 30 17 47 123 198 245 120 180 227 173
 ? G212 1 7 248 71 1 170 170 170 15 99 100 161 58 8 0 154 136 247 114 97 255

Hab's noch nicht mit den Daten von Kleiner abgeglichen, weiss nicht ob's Sinn macht...

[trilu]

Schade, ich hatte gehofft das wir nicht an die jeelib ran müssen.
Aber auch der String mit 0g ist nicht komplett. Da sind nur 3 AA drin, wir brauchen mindestens 4.
Wenn du noch Zeit und Lust hast, kannst du ja noch ein wenig an der Funkstrecke arbeiten.
Ich werde mir morgen mal die jeelib ein wenig genauer anschauen.

[ohweh]

Hi Trilu,

ich glaube mittlerweile, dass der "gefüllte" 0g String absoluter Bogus ist. Nach nem Reset ist rf12_data leer, daher auch die Nullen. Sobald man aber mit 0g an den Start geht, kassiert man unerwünschte Pakete, die mitunter wiederum recht lang sind. Der rf12_data buffer wird aber nie gelöscht, sondern immer nur das Längenbyte ausgewertet. Und genau dass wird ignorieren wir ja bewusst...

Hier ist ein gutes Beispiel dafür (mit 212g):

 ? 1 7 248 71 0 170 170 170 0 0 0 0 0 0 0 0 0 0 0 0 0
 ? 1 7 248 71 0 0 0 170 0 0 0 0 0 0 0 0 0 0 0 0 0
 ? 1 7 248 71 0 170 170 170 0 0 0 0 0 0 0 0 0 0 0 0 0
 ? 1 7 248 71 0 0 0 170 0 0 0 0 0 0 0 0 0 0 0 0 0
 ? 113 184 222 88 47 139 168 254 43 128 255 201 130 89 226 39 149 56 21 188 185
 ? 1 7 248 71 0 170 170 254 43 128 255 201 130 89 226 39 149 56 21 188 185
 ? 1 7 248 71 0 0 0 254 43 128 255 201 130 89 226 39 149 56 21 188 185
 ? 1 7 248 71 0 170 170 254 43 128 255 201 130 89 226 39 149 56 21 188 185

Deinem Ansatz mit den 4 AAs kann ich folgen, ist sicherlich vielversprechend genau dort anzufangen. Dann ist der Rest vermutlich "einfach". Bin echt gespannt ob Du mit der JeeLib weiter kommst, bzw. überhaupt dort nen Ansatz findest. Ich hab da auch mal reingeschaut, das ist ein heftiger Brocken, das überschreitet gerade meinen Horizont ;-)

Empfang ist jetzt auch viel besser, musste einen Tick runter mit der Frequenz (bin jetzt mit A700 unterwegs). Nu seh ich alle Pakete doppelt. Kann jetzt:

- noch ein RF12 Setting Problem sein... werde die Grenzen von Freq. und Data Rate morgen mal ermitteln und dann die goldene Mitte nehmen.
- alle Pakete werden wirklich doppelt gesendet
- ggf. ist das "doppelte" Paket auch nur der ACK samt Payload der Steckdose?

Sieht doch alles schonmal sehr gut aus, da freu ich mich glatt auf morgen früh ;-)

/Oliver

[trilu]

Meine Hoffnung war das in dem payload buffer der komplette String enthalten ist und nur nicht angezeigt wird,
weil das Längenbyte nicht stimmt.
Dank deines Tests wissen wir jetzt, das nicht der komplette String enthalten ist :-)

Ich denke das etwas mit den Funksettings noch nicht stimmt. Doppelt senden sollte bei den RF12 Modulen nicht nötig sein,
da sie ja bidirektional kommunizieren können.
Doppelt und dreifach Senden machen eigentlich nur die 433Mhz Dinger und IR Fernbedienungen, da sie ja nicht Wissen ob die
Info empfangen wurde. Bei RF12 kann man dafür den Mechanismus des ACK nutzen. ACK sollte aber nicht einfach den String
wiederholen, das wäre Verschwendung von Senderesourcen.

So wie "kleiner" geschrieben hat, fängt wohl die Basisstation an eine Anfrage an den Adapter zu senden:
TX: AA AA AA 2D D4 01 04 07 F8 92 00 AA AA AA AA 71 52 AA AA AA

und der Steckdosenadapter antwortet mit:
RX: 01 04 07 F8 92 00 00 00 00 00 0E 9F

Mir fällt gerade was auf in dem String - das sollten wir mal beobachten wenn wir mit dem pairen starten.
Die 07 könnte auch das Längenbyte sein. Das was danach kommt ist ja die Checksumme.

Die Frage die sich jetzt stellt - was soll eigentlich das Ergebnis der Aktion sein?
Da wir im Fhem Forum sind sollte das Ziel sein die PCA 301 an Fhem betreiben zu können.

Eingabegerät am Fhem ist damit der Jeestick.
Soll der Jeestick weiterhin für die Jeenode's etc. genutzt werden können oder reservieren wir den Stick ausschließlich für PCA 301?
Für den RF12demo sketch gibt es bereits ein fhem Modul zur Integration, für ein "eigenes" Protokoll müssten wir so etwas schreiben?

[trilu]

Hab mir gerade noch einmal den SPI Log angeschaut
5B [5C C6 0xC6(FF 0xFF)5C 33 0x33(FF 0xFF)5D ] = C633 = Data Rate =6.631kbps
5B [5C 94 0x94(FF 0xFF)5C C5 0xC5(FF 0xFF)5D ] = 94C5 = Receiver Control, LNA Gain: max dB, RX Bandwidth: 67 kHz, Pin: VDI, VDI: Fast, DRSSI: -73 dB
5B [5C 98 0x98(FF 0xFF)5C 20 0x20(FF 0xFF)5D ] = 9820 = TX Control, Frequency Shift: Pos, Deviation: 45 kHz
5B [5C C2 0xC2(FF 0xFF)5C AF 0xAF(FF 0xFF)5D ] = C2AF = Data Filter & Clock Recovery, Filter Type: Digital, Quality Threshold: 7, Recovery Mode: Auto, Recovery Speed: Slow
5B [5C C4 0xC4(FF 0xFF)5C 77 0x77(FF 0xFF)5D ] = C477 = Automatic Frequency Control, AFC Mode: Runs only once after power up,Offset Register Limit: +3 .. -4, Enable AFC: on, Strobe: off, Enable High Accuracy (slower): on, Enable Frequency Offset Register: on
5B [5C CC 0xCC(FF 0xFF)5C 76 0x76(FF 0xFF)5D ] = CC76 = PLL Settings
5B [5C E1 0xE1(FF 0xFF)5C 96 0x96(FF 0xFF)5D ] = E196 = Wake-Up Timer
5B [5C C8 0xC8(FF 0xFF)5C 0E 0x0E(FF 0xFF)5D ] = C80E = Low Duty-Cycle
5B [5C C0 0xC0(FF 0xFF)5C C0 0xC0(FF 0xFF)5D ] = C0C0 = Low Battery Detect and µC Clock
5B [5C 80 0x80(FF 0xFF)5C E8 0xE8(FF 0xFF)5D ] = 80E8 = Configuration Settings, Band: 868 MHz, Xtal capp: 12,5pF, TX Register: on, RX FIFO Buffer: on
5B [5C A7 0xA7(FF 0xFF)5C 08 0x08(FF 0xFF)5D ] = A708 = Center Frequency =869.0000MHz
5B [5C CA 0xCA(FF 0xFF)5C 83 0x83(FF 0xFF)5D ] = CA83 = FIFO and Reset Mode, FIFO INT Level: 8, FIFO Fill Start: Sync, FIFO Fill Enabled: on, Sync on: 2bytes, Reset Sensitivity: low
5B [5C 82 0x82(FF 0xFF)5C 38 0x38(FF 0xFF)5D ] = 8238 = Power Management

Was du definitiv setzen solltest:
C633 = Data Rate
94C5 = Receiver Control
9820 = TX Control
C2AF = Data Filter & Clock Recovery
C477 = Automatic Frequency Control
CC76 = PLL Settings
C80E = Low Duty-Cycle
80E8 = Configuration Settings
A708 = Center Frequency
CA83 = FIFO and Reset Mode

[ohweh]

Guten Morgen ;-)

War schon fleissig und hab nen Blick in die JeeLib geworfen. Wenn das Packet "ungültig" ist, wirft sie rf12_len + 5 aus, und geht dann auf Idle. Hab das jetzt mal fest auf 10 erweitert ("schön" ist das nicht gerade...)

Dazu noch das Längenbyte mit ausgegeben (in der RF12demo an derselben Stelle, wo wir gestern schon rumgehext haben).

Und hier mal ein bisschen Output:

Current configuration:
 _ i31 g212 @ 868 MHz
 ? 1 5 7 248 71 0 170 170 170 170 0 0 0 0 0 0 0 0 0 0 0 0
 ? 1 5 7 248 71 0 170 170 170 170 111 234 170 168 0 0 0 0 0 0 0 0
 ? 1 5 7 248 71 0 170 170 170 170 111 234 170 168 0 0 0 0 0 0 0 0
 ? 1 5 7 248 71 0 170 170 170 170 111 234 170 168 0 0 0 0 0 0 0 0
 ? 1 5 7 248 71 0 170 170 170 170 111 234 170 178 0 0 0 0 0 0 0 0
 ? 1 5 7 248 71 0 170 170 170 170 111 234 170 178 0 0 0 0 0 0 0 0
 ? 1 5 7 248 71 1 170 170 170 170 111 234 170 178 0 0 0 0 0 0 0 0
 ? 1 5 7 248 71 1 170 170 170 170 239 145 170 168 0 0 0 0 0 0 0 0
 ? 1 5 7 248 71 1 170 170 170 170 239 145 170 168 0 0 0 0 0 0 0 0
 ? 1 5 7 248 71 1 170 170 170 170 239 145 170 168 0 0 0 0 0 0 0 0
 ? 1 5 7 248 71 1 170 170 170 170 239 145 170 130 0 0 0 0 0 0 0 0
 ? 1 5 7 248 71 1 170 170 170 170 239 145 170 130 0 0 0 0 0 0 0 0
 ? 1 4 7 248 71 0 170 170 170 170 239 145 170 130 0 0 0 0 0 0 0 0
 ? 1 4 7 248 71 0 170 170 170 170 233 137 170 130 0 0 0 0 0 0 0 0
 ? 1 4 7 248 71 0 170 170 170 170 233 137 170 130 0 0 0 0 0 0 0 0
 ? 1 4 7 248 71 1 0 3 170 170 233 137 170 130 0 0 0 0 0 0 0 0
 ? 1 4 7 248 71 1 0 3 0 0 22 137 170 130 0 0 0 0 0 0 0 0
 ? 1 4 7 248 71 1 0 3 0 0 22 3 170 130 0 0 0 0 0 0 0 0
 ? 1 4 7 248 71 0 170 170 0 0 22 3 170 130 0 0 0 0 0 0 0 0
 ? 1 4 7 248 71 0 170 170 170 170 233 137 170 130 0 0 0 0 0 0 0 0
 ? 1 4 7 248 71 0 170 170 170 170 233 137 170 130 0 0 0 0 0 0 0 0
 ? 1 4 7 248 71 1 0 9 170 170 233 137 170 130 0 0 0 0 0 0 0 0
 ? 1 4 7 248 71 1 0 9 0 0 22 137 170 130 0 0 0 0 0 0 0 0
 ? 1 4 7 248 71 1 0 9 0 0 22 139 170 130 0 0 0 0 0 0 0 0

Wegen der Funksettings werde ich später (entweder heute oder morgen) nochmal rumprobieren. Mir kommt das auch irgendwie komisch vor. Ich schau mal was sich ändert wenn man mit einzelnen Settings rauf/runter geht.

Das mit dem "neuen" Längenbyte von 07 hab ich noch gar nicht gesehen! Klasse, das würde echt Sinn machen...

Tja, irgendwie wusste ich dass die Frage nach FHEM früher oder später aufkommt ;-) Ich hab's nicht im Einsatz, kann da nix zu sagen. Für mich ist das hier (noch) Grundlagenforschung, also

- was wird wirklich über RF12 versendet
- wie oft wird was versendet, bzw. was muss die Dose "antworten" wenn sie geschaltet wird
- wie ist die Pairing Sequenz?
- CRC Berechnung um defekte Pakete auszuschliessen
- ich brauche unbedingt nen Ersatz für die Anzeige-/Schalteinheit

Bzgl. des eigens dafür abzustellenden JeeNode/JeeLink: Ich glaube ohne wird's wohl schwer. Die Settings sind so weit ab von JCWs Standard, dass ich normale Pakete nicht mehr empfangen kann. Mögliche Auswege wären dann:
- alle anderen JeeNodes auf die neuen Frequenzen festdengeln (wobei die Bitrate echt niedrig ist...)
- oder aber den Sketch so modifizieren, dass man zwischen verschiedenen RF Settings hin- und herschalten kann (wie JCW das beim OOK Relay macht). Hat dann aber den dicken Nachteil, dass man Pakete vom anderen Band "verliert"...

Bzgl. FHEM: Ein "JeeStick" ist aber ein Standard JeeNode/JeeLink, richtig? Mich würde es nicht stören an dem Sketch mitzuwirken, den kann man ja später ohne Probleme abwandeln. Wer weiss, vielleicht komme ich noch auf den FHEM Geschmack? ;-))

/Oliver

[ohweh]

Danke für die Mühe mit dem Auswerten des Logs. Ich hatte bisher nur die Hälfte der Settings, bin gestern nicht mehr weiter gekommen. Aber nu sind alle drin. Deine Reihenfolge der Settings kann ich so übernehmen?

Hab ich jetzt mal 1:1 übernommen (inkl. Reihenfolge):

- Erstmal sehe ich gar keine Pakete (auf A708)
- Sobald ich mit der Frequenz um einen Tick runtergehe (A707), dann kommt was. Bis hinunter zu A6F6.

Problem ist jetzt, dass alle Pakete 3-10x reinkommen. Das variiert ein bisschen mit der Frequenz, aber es gibt keine wo ich ein Paket genau 1-2 mal sehe... Irgendwas ist da noch faul. Aber "Müll" sehe ich auch nicht, d.h. der Empfang ist gut.

Auch wenn's spannend ist, ich klink mich jetzt mal ein paar Stunden aus. Die Sonne lässt grüssen ;-)

/Oliver

[trilu]

JeeNode und JeeLink sind fast identisch - der JeeLink hat noch einen Eeprom mit drauf und nur ein paar Pins nach außen geführt.
Funktion entspricht aber der Jeenode.

Ich denke auch, das hin und herschalten macht wenig Sinn weil wir ja ein bidirektionales Protokoll haben.
Ist ja nicht nur Senden und sofort wieder in den anderen Bereich zurück schalten, sondern es ist ein Request senden, auf
Antwort warten, wenn keine kommt noch mal senden und wieder warten.
Der Vorteil eines eigenen JeeLinks ist, wir können den Source so umbauen wie wir ihn brauchen und müssen keine Rücksicht auf Kompatibilität nehmen.

Ich würde vorschlagen du versuchst jetzt die Funkstrecke etwas stabiler zu bekommen. Die Settings müssten so wie sie in dem Post weiter oben sind passen.
Wenn das steht, dann bauen wir den Sketch so um, dass du über die serielle auch mal Anfragen raussenden kannst.

[ohweh]

Hey,

ja, kenn den Unterschied zwischen den beiden. War mir jetzt nur nicht sicher, ob mit "JeeStick" nicht wieder sowas spezielleres wie der HAH-Node gemeint ist, also ne Sonderversion für FHEM. Und die dann nen besonderen Namen gekriegt hat (wegen besonderem Bootloader, Layout, oder so).

Also ich seh's wie Du, lieber einen JeeLink/JeeNode abstellen der dann auch alles mitkriegt und mit den Dosen vernünftig und vor allem bidirektional agiert. Hab hier ne Menge FS20-Steckdosen, die will ich loswerden. Sind mir nicht (mehr) zuverlässig genug. Dieses Prinzip "lass uns einfach mal was rausschicken, das Band wird schon frei sein" funktioniert hier an meinem Wohnort nicht so wirklich dolle... Viele andere werden aber sicherlich wenig Probleme damit haben. Standortabhängig eben...

Hinzu kommt, dass ich diese "wir stellen einen Jeelink ab" schon für die Energy Monitor 3000 Büchsen gemacht hab. Die sind im Prinzip gut, der Jeelink kommt auch gut damit klar, aber die Reichweite ist halt nicht soooo prickelnd. Und schalten kann man damit auch nicht, deswegen will ich ja (wie Du auch) den Versuch mit der PCA 301 starten. Klappt das, fliegt hier einiges raus.

Lange Rede, kurzer Sinn: Lass uns den Source umbauen ;-)

Wo wir beim Thema "umbauen" sind... Manchmal ist es gut zu gehen, und später wieder zu kommen. Hab ich gemacht (leicht angesickt ;-), und mir eben nochmal die beschriebene Änderung in der JeeLib angeschaut. Und damit rumgespielt (zum Teil auch rückgängig gemacht). Sieht so aus als hätte ICH die "doppelten" Pakete damit selbst verursacht... Folgendes habe ich jetzt geändert:

In der RF12.cpp wie folgt geändert:

if (rxstate == TXRECV) {
        uint8_t in = rf12_xferSlow(RF_RX_FIFO_READ);

        if (rxfill == 0 && group != 0)
            rf12_buf[rxfill++] = group;
           
        rf12_buf[rxfill++] = in;

        rf12_crc = _crc16_update(rf12_crc, in);

        // ohweh - quick hack - for group 212, add 4 to rf12_len
        if (rxfill == 3 && rf12_grp == 212)
            rf12_len += 4;
        // ohweh - end hack

        if (rxfill >= rf12_len + 5 || rxfill >= RF_MAX)
            rf12_xfer(RF_IDLE_MODE);
    } else {
        uint8_t out;


Und im RF12demo Sketch wiederum dies abgeändert:

   if (useHex)
      Serial.print('X');
    if (config.group == 0) {
      Serial.print(" G");
      showByte(rf12_grp);
    }
    Serial.print(' ');
    showByte(rf12_hdr);

    // --- ohweh - Trilu's Quick Hack ---------------------------
    if (rf12_grp == 212 && rf12_hdr == 1) {
      Serial.print(' ');
      showByte(rf12_len - 4);
      n = 10;
    }
    // --- ohweh - end hack -------------------------------------

    for (byte i = 0; i < n; ++i) {
      if (!useHex)
        Serial.print(' ');
      showByte(rf12_data);
    }
   
    Serial.println();
   
    if (rf12_crc == 0) {
      activityLed(1);


Kompiliert, gestartet, nix... Runter mit der Frequenz auf A706, dann das hier:

Current configuration:
 _ i31* g212 @ 868 MHz
A708
A707
A706
 ? 1 4 7 248 71 0 170 170 170 170 233 137
 ? 1 4 7 248 71 1 0 13 0 0 150 216
 ? 1 4 7 248 71 0 170 170 170 170 233 137
 ? 1 4 7 248 71 1 0 19 0 0 151 64
 ? 1 4 7 248 71 0 170 170 170 170 233 137
 ? 1 4 7 248 71 1 0 15 0 0 22 243

Sieht gut aus, oder? Vor allem wenn ich jetzt dazu sage, dass die Pakete oben einen Zeitraum von > 180 Sekunden umfassen ;-) D.h. eine Anfrage des Senders, eine Antwort der Dose. An der Dose hängt übrigens ein Schrottnetzteil mit Trafo dran, brauchte irgendwas mit Last, und das kam mir recht. Also nicht über fehlende Nullen wundern...

Was mich noch dazu bringt, dass bei einem Aus- und Einschalt-Vorgang im Anschluss eine wahre Paketflut losbricht. Es ist mitnichten so, dass die Empfangseinheit dann nur alle 60 Sekunden fragt, sondern es werden im Abstand sehr weniger Sekunden die Werte upgedatet. Und irgendwann geht's dann in den normalen Rhythmus von 60s über. Die genauen Werte muss ich bei Gelegenheit mal ermitteln.

Was mir jetzt gar nicht gefällt, ist die Tatsache, dass wir wohl um die Änderung der JeeLib nicht herumkommen. Und das ist ja irgendwie nicht dolle, JCW ändert sie ja doch recht häufig, und die Updates möchte ich nicht missen. Hast Du ne Idee für ein Grundgerüst des Sketches der alles beinhalten und die Einbindung der JeeLib überflüssig macht?

/Oliver

[ohweh]

Hi Trilu,

es gibt Neuigkeiten. Hab's geschafft den CRC zu berechnen, und damit Pakete als gültig/ungültig zu detektieren ;-) Dann mal nen Reichweiten-Test gemacht:

- 3 Wände? - GEHT!
- 3 Stahlbeton-Decken? - GEHT auch ;-)
- Noch weiter vielleicht? Nääää, da ist echt Feierabend... Sowohl beim JeeLink, als auch bei der Anzeigeeinheit.

Vielleicht kann man durch Optimierung (bessere Antenne wie beim CUL oder so) evtl. noch ne Wand/Decke mehr rausschlagen?? Keine Ahnung, vielleicht... Aber für den Gebäudeeinsatz ist das Ding in Punkto Reichweite schonmal nicht soooo übel.

Nen kleinen Nachteil gibt's auch schon zu vermelden: Die Dose puffert/speichert ihren aktuellen Schaltzustand nicht, nach nem Stromausfall ist die Dose automatisch "ausgeschaltet". Aber das kann man ja leicht in Logik nachbessern.

Soweit, so gut... Kommen wir zum Thema Pairing.

1.) Ausgangszustand: Anzeigeeinheit ist aus (keine Batterie). Neue PCA 301 eingesteckt + Pairing Modus aktiviert

2.) Im Abstand von 2 Sekunden sendet die Dose insgesamt 30 identische Pakete:

    00 11 07 F9 2F AA AA AA AA AA

3.) Während die Dose noch dabei ist, ihre 30 Pakete loszuwerden (die bisher nicht beantwortet wurden), wurde die Batterie in die Anzeigeeinheit eingelegt. Dabei springt sie automatisch zum nächsten unbelegten Kanal und geht in den Pairing-Modus... Hier ist es der Kanal "4". Folgendes Paket wird von der Anzeigeeinheit zur Dose gesendet:

    04 04 07 F9 2F 00 AA AA AA AA

4.) Dose antwortet mit:

    04 04 07 F9 2F 00 00 00 00 00

5.) Ergebnis: GEPAIRED! ;-)

6.) Heisst im Klartext die Dose broadcastet ihre ID (hier F92F) auf Kanal 0, die Anzeigeinheit übernimmt sie und ordnet sie einem freien Kanal zu. Dieser Kanal wiederum wird der Dose übermittelt. Mehr scheint da nicht im Spiel zu sein (oder aber die JeeLib unterschlägt mir Daten... da die CRCs zu obigen Paketen aber stimmen, glaube ich erstmal an diese Erkenntnis.

Fehlt noch die Sendemöglichkeit... Haste schon ne Idee wie's elegant geht?

/Oliver

[ohweh]

Ich hab noch was vergessen...

Manch könnte ja auf die Idee kommen einen Sketch zu bauen der nur "lauscht" um den aktuellen Stromverbrauch zu ermitteln?!?!? Also der Anzeigeeinheit das Polling überlässt und nur die Rückgabe-Daten auswertet?!?! Vergesst es lieber ;-)

Problem ist folgendes: Die Anzeigeeinheit ruft i.d.R. alle 60 Sekunden die aktuellen Daten auf dem gerade gewählten Kanal ab (Ausnahme dieser Regel ist, wenn die Dose gerade eingeschaltet wurde). Auf ALLEN anderen Kanälen werden die Daten nur alle 900 Sekunden (=15 Minuten) abgefragt. Das wird vermutlich den wenigsten genügen...

[trilu]

Hi Oliver,
Sorry, hatte am Wochenende so gut wie keine Zeit.
Ich werd morgen mal anfangen eine Struktur fuer den pca301 sketch zu basteln und jee Funktionen zu portieren.
Das mit den sample strings zum pairen ist schon mal sehr hilfreich...
Viele Grüsse
Horst

[ohweh]

Hi Horst,

hab Dir gerade gerade schonmal was geschickt, ich denke das spart Arbeit. Hoffe ich zumindest ;-) Schau mal in Deine PM.

Gruss

Oliver

[trilu]

gerade angeschaut :-)
sieht schon mal nicht schlecht aus - aber was hältst du davon das wir eine eigene lib daraus machen.
also eine pca301 lib, inkl. pairing funktion, etc...
den sketch lassen wir frei für ein/ausgabe steuerung usw...

hilfreich wäre, wenn wir noch jemand gewinnen könnten, der sich mit fhem vernünftig auskennt und uns bei der
einbindung in fhem mit rat und tat zur seite steht.
derzeit frage ich mich, wie sollten die strings an der seriellen aussehen, welche daten müssen richtung fhem
geschaufelt werden, wie sieht die struktur aus, die vermutlich zurück kommt...

fragen über fragen :-)

[ohweh]

Moin ;-)

Ne eigene lib? Ja, hört sich sehr gut an. Würde den Ein-/Ausgabe-Teil ja wirklich übersichtlich gestalten... Haste denn da auch schon ne Vorstellung bzgl. eines Grundgerüsts?

Wg. FHEM: Irgendwie ist das echt lustig hier ;-) Lustig in dem Sinne, dass alle die, die sich mit dem Thema PCA 301 ernsthafter auseinander setzen, aktuell FHEM nicht am Start haben. Und andere, die es wiederum nutzen, hoffen wohl darauf, dass ne fertige Lösung für sie vom "Himmel" fällt... Bin jetzt mal gespannt...