SIGNALDuino
SIGNALDuino copied to clipboard
RFD-FHEM
Version CC11xx
@sidey79 Im Commit https://github.com/RFD-FHEM/SIGNALDuino/commit/f949589d948ac9eebd5396a2e428131c850e7d01 setzt du den Chip auf CC1101, wenn 0x17 gelesen wurde. Laut Datenblatt https://www.ti.com/product/CC110L Seite 76 handelt es sich dabei aber eindeutig um einen CC110L. Das die Beschriftung bei dem User im Issue https://github.com/RFD-FHEM/SIGNALDuino/issues/127#issuecomment-643328778 nicht mit der Version übereinstimmt, würde ich erst mal in Frage stellen. Vielleicht ist der Chip ja umgelabelt.
Ich würde das besser ändern in:
case 0x17:
case 0x07:
MSG_PRINT("L");
break;
In "case 0x07" ist übrigens auch noch ein "break" zuviel.
Anstelle von "chip CC110 unknown" wäre es vielleicht auch noch ganz günstig, die Versionsnummer mit auszugeben. So in der Art: "chip CC110 unknown 0x018"
Hab das mit der chipid zusammen mit einem Syntax Fehler korrigiert.
Vielleicht sollten wir einfach immer nur die chipid ausgeben und keine Bezeichnung von dem Chip selbst?
Die Idee hatte ich auch, zumal ja beim Nano und ganz besonders beim Radino der Flash knapp wird. Die Umwandlung der ChipId in eine Bezeichnung könnte dann in FHEM erfolgen.
Stimmt, die Umwandlung ist über ein Perl Modul besser und universeller zu realisieren.
Wenn Du magst, kannst Du ja einen pr machen oder warten bis ich das anpasse
Als Ausgabe vom SIGNALduino würde ich dann vorschlagen:
statt bisher:
V 3.4.0-dev SIGNALduino cc1101 (chip CC1101) - compiled at Feb 15 2020 23:23:10
wird daraus:
V 3.4.0-dev SIGNALduino cc1101 (version 20) - compiled at Feb 15 2020 23:23:10
oder in hex:
V 3.4.0-dev SIGNALduino cc1101 (version 0x14) - compiled at Feb 15 2020 23:23:10
Wenn ich überlege, hat die chipid eigentlich nichts im versionsstring der Firmware zu suchen. Wir können doch einfach das Register anfragen und die Information in ein Reading packen
Das ist natürlich auch eine Option, aber so wie es jetzt ist, haben wir alle Infos von einem Gerät z.B. nach dem Flashen der Firmware in einem Rutsch. Ich habe dafür jetzt etwas vorbereitet. Das sähe dann so aus:
Radino
V 3.4.0-dev_2020-06-17 SIGNALduino cc1101 (433 Mhz, 0x14) - compiled at Jun 17 2020 18:04:25
Nano
V 3.4.0-dev_2020-06-17 SIGNALduino cc1101 (0x03) - compiled at Jun 17 2020 20:33:30
V 3.4.0-dev_2020-06-17 SIGNALduino cc1101 (0x14) - compiled at Jun 17 2020 20:33:30
ESP8266
V 3.4.0-dev_2020-06-13 SIGNALESP cc1101 (0x14) - compiled at Jun 17 2020 20:50:06
Aber die chipid hat nichts mit der firmware ansich zu tun und gehört auch nicht in die Versionsanzeige.
Es ist ja sowieso nur eine Information auf die man nicht viel geben kann oder?
Nur wegen einem bekannten Fall zu schlussfolgern, das diese Information nicht zuverlässig ist, halte ich für überspitzt. Ich kann zumindest schon mal für 9 Stück CC11xx belegen, das die Version passt.
Wenn ich überlege, hat die chipid eigentlich nichts im versionsstring der Firmware zu suchen. Wir können doch einfach das Register anfragen und die Information in ein Reading packen
Die Info auszugeben wird schon praktisch sein.
JA, mit der Version an sich hat dies nichts zu tun aber dann müsste man auch das cc1101 weglassen.
Die Variante von @elektron-bbs https://github.com/RFD-FHEM/SIGNALDuino/issues/133#issuecomment-645568709 finde ich aussagekräftig genug. So ist alles in einem und wir vermehren keine Internals oder Readings.
cc1101 kommt in die Versionsgabe, weil es beim compilieren mit compiliert wird oder eben nicht.
Die chipid wird ja nicht zur Compiler Zeit eingebaut. Irgendwer hatte das mal vor langer Zeit eingebaut.
Mir fällt aber kein Grund ein, wieso wir nicht alle Register gleich behandeln und diese einzeln abfragen wenn benötigt.
cc1101 kommt in die Versionsgabe, weil es beim compilieren mit compiliert wird oder eben nicht.
Das ist eigentlich noch ein Grund, warum die Ausgabe des aktuell ausgelesenen Registers mit in die Versionszeile sollte. So sehe ich sofort, ob die Kommunikation mit dem CC11xx prinzipiell noch funktioniert. Wenn dort 0x00 erscheint, ist etwas faul. Du kannst natürlich auch z.B. nach der Versionsabfrage zusätzlich noch eine Abfrage des Registers einleiten. Das müsste dann auch bei jedem Reset oder Init u.s.w. erfolgen.
Gleich behandelt werden auch jetzt nicht alle Register. Ein "get sduino ccreg 31" bringt die Meldung "unknown Register 31, please choose a valid cc1101 register". Die Status-Register lassen sich momentan nicht abfragen. Wenn ich die entsprechende "if (exists($cc1101_register..." Abfrage auskommentiere, bekomme ich die Ausgabe:
ccreg:
Configuration Register Detail address (name) = value:
0x31 ( ) = 0x14
Das müsste man dann halt etwas umschreiben: Statt "Configuration Register" halt "Status register".
Wieso gehört die Kommunikation zum cc1101 in die Versionsabfrage will sich mir nicht erschließen. Mit der Version des SIGNALduino hat es doch nichts zu tun ob die Kommunikation läuft oder nicht.
Gegen das Abfragen der Statusregister spricht doch wenig. Mit der Frequenz machen wir das doch auch.
Wieso gehört die Kommunikation zum cc1101 in die Versionsabfrage will sich mir nicht erschließen. Mit der Version des SIGNALduino hat es doch nichts zu tun ob die Kommunikation läuft oder nicht.
Mit der Firmware-Version des SIGNALduino hat es tatsächlich nichts zu tun.
Gegen das Abfragen der Statusregister spricht doch wenig. Mit der Frequenz machen wir das doch auch.
Das wird dann halt wieder ein größerer Umbau. Ich dachte an eine schnelle, einfache Lösung...
Ich denke, es würde ausreichen das Register 31 genau so abzufragen wie die Frequenz. Sollte keine riesen Aktion werden und die Firmware kann es schon
Ich hatte schon mal eine Tabelle mit in Frage kommenden Transceivern zusammengestellt:
PARTNUM | VERSION | Radio | Frequency bands (MHz) | Description
---------|---------|-----------|---------------------------------------------------------------------------------------------------------
0 | 3 | CC1100 | 300-348, 400-464, 800-928 | low-cost sub-1 GHz transceiver
0 | 4 | CC1101 | 300-348, 387-464, 779-928 | Low-power Sub-1 GHz wireless transceiver
0 | 4 | CC1101-Q1 | 310-348, 420-450, 779-928 | Low-Cost Low-Power Sub-1-GHz RF Transceiver
0 | 14 | CC1101 | 300-348, 387-464, 779-928 | Low-power Sub-1 GHz wireless transceiver
0 | 5 | CC1100E | 470-510, 950-960 | Low-power Sub-1 GHz wireless transceiver for China and Japan frequency bands
0 | 7 | CC110L | 300-348, 387-464, 779-928 | Value line Sub-1 GHz wireless transceiver
0 | 17 | CC110L | 300-348, 387-464, 779-928 | Value line Sub-1 GHz wireless transceiver
0 | 8 | CC113L | 300-348, 387-464, 779-928 | Value line Sub-1 GHz wireless receiver
0 | 18 | CC113L | 300-348, 387-464, 779-928 | Value line Sub-1 GHz wireless receiver
0 | 15 | CC115L | 300-348, 387-464, 779-928 | Value line Sub-1 GHz wireless transmitter
Bitte ergänzen, falls noch weitere Typen bekannt.
@HomeAutoUser Mein Standpunkt ist, dass wir es ins Modul einbauen sollten. Passt prinzipiell sogar in eine Bibliothek, da es nichts mit dem Signalduino ansich sondern mit dem CC1101 zu tun hat.
Wie
- meinst du dies, das es prinzipiell in eine Bibliothek passen würde?
- gedenkst du die Umsetzung?
Mit diesen genaueren Angaben habe ich vielleicht mehr Vorstellungskraft, um das umsetzen.
Ich meinte damit ein Perl Modul und kein Fhem Modul, was einem die hexcodes in Text übersetzt.