SIGNALDuino Empfänger Firmware V 3.3.2r-dev

Begonnen von Ralf9, 07 Januar 2018, 21:37:44

Vorheriges Thema - Nächstes Thema

Beta-User

Bevor Ihr spekuliert:
Das mit den addons ist toll, und das geht heute schon mit der normalen CUL-Maple-Firmware, v.a. für "Fertiggerät" wie das HM-PI-PCB oder den CC2531 (zigbee2mqtt), und man kann "nebenbei" auch einen Signalduino aufsatteln.
Da der Teil mit den drei seriellen Schnittstellen "reine STM-Basis" ist, ist es vermutlich nicht so schwer, das für den Signalduino zu adaptieren.

Der Vorschlag geht aber noch etwas weiter (bzw. das war der ursprüngliche und erste Gedanke (ausgehend von der Feststellung, dass auf dem ATMega32 der Platz eng wird):
Die CUL-Firmware hat die Stärke, dass viel in der firmware selbst erledigt wird, was v.a. auch für diverse Sonderprotokolle "neben HM-BidCoS und ZWave" angeht, der Signalduino ist schon immer und jetzt noch mehr super, wenn es um die flexible Auswertung von irgendwas seltenerem oder unbekannterem oder eben von "generischem Zeug" wie IT geht. (@Ralf9, Sidey&Co: Seht mir nach, wenn das etwas zu flapsig oder technisch gesehen unsauber ist...  ich bin da auch nicht wirklich Experte).
Die eigentliche Idee wäre, jeden CC1101 dann (mehr oder weniger frei) wahlweise im "CUL-(xyz-)Mode" oder "Signalduino-Mode" ansprechen zu können und den "Nebeneffekt" mit den beiden zusätzlichen Schnittstellen mitzunehmen...

Hoffe, das ganze ist jetzt besser verständlich. (Ob das auch ganz oder in Teilen umsetzbar, ist eine ganz andere Frage...)

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Ralf9

Zitat von: Beta-User am 07 Januar 2020, 11:17:23
Wunschliste II: MapleSignalduino (mit LAN+durchgereichten seriellen Interfaces, auf MapleCUN-Basis)...
Es gibt anscheinend außer mir noch andere die lieber LAN als WLAN verwenden wollen.
Für den SIGNALDuino auf dem Maple Mini gibts ein eigenes Thema
https://forum.fhem.de/index.php/topic,106278.msg1010356.html#msg1010356

ZitatDie eigentliche Idee wäre, jeden CC1101 dann (mehr oder weniger frei) wahlweise im "CUL-(xyz-)Mode" oder "Signalduino-Mode" ansprechen zu können und den "Nebeneffekt" mit den beiden zusätzlichen Schnittstellen mitzunehmen...
Dies ist wahrscheinlich nicht oder nur mit sehr großem Programmieraufwand möglich. Der seitherige normale OOK Modus, indem die Länge der empfangenen Pulse gemessen wird, ist sehr zeitkritisch.
Außer den bidirektionalen Protokollen müsste alles was der cul kann mit überschaubarem Aufwand auch mit dem Signalduino empfangen werden können.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Ralf9

Zitat von: sash.sc am 07 Januar 2020, 10:59:49
Besteht die Möglichkeit, das der Signal Duino  dann mit 2 cc1101 arbeiten kann, für beide Frequenzen (433 und 868)?

Sonst bräuchte man für jede frequenz nen eigenen sduino?

Dies wird mit der jetzigen Arduino Hardware wahrscheinlich nicht gehen. Mit dem Maple Mini müsste es machbar sein.

Was demnächst gehen müsste, wenn Du nichts senden möchtest, ist per Timer zwischen den EEPROM Speicherbänken umzuschalten.
Wenn die Sensoren nicht so weit weg sind, empfängt der 868 cc1101 auch recht brauchbar die 433 Sensoren, auch durch eine Betondecke.

Wenn Du z.B. auf der Bank 0 eine cc1101 Register konfiguration für 433 MHz und auf Bank 1 eine Register konfiguration für LaCrosse hast,
dann kannst Du dies dann so konfigurieren, daß z.B. für 10 Min die Register konfiguration von Bank 0 und dann für 30 Sek Bank 1 für LaCrosse aktiv ist, und dann wieder Bank 0 ...
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Beta-User

Ja, WLAN ist mMn. kurz vor dem 433MHz-Gedöns (das man leider nicht immer vermeiden kann...) so ziemlich das letzte, was man sich freiwillig für was wichtiges im Bereich der HA antun sollte... (haben wir nicht grade wieder jemanden, der sich wundert, dass die Fritte das nicht packt. Und Passwörter wechselt auch keiner mehr bei >20 Geräten :P .)

Was +CUL angeht: Wenn das mit dem Maple/LAN klappt, ist sowieso alles gut, das bidirektionale Zeug (HM, z.B.), ist sowieso auf "eigenen" Interfaces besser aufgehoben!

Danke für den Link, vielleicht komme ich mal dazu, da mitzutesten :) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Ralf9

Irgendwas passt mit dem 36_LaCrosse Modul nicht, es scheint mir irgendwie mein ganze fhem durcheinander zu bringen.
Ich wandle die LaCrosse Rohdaten in das LaCrosse Format
z.B.
OK 9 43 129 4 210 50

Ich habe meine firmware auf einem nanocul und auf einer minicul Hardware, auf beiden ist eine Registerkonfiguration für den LaCrosse Mode 1 Empfang.
Damit kann ich problemlos meinen TX29 DTH-IT empfangen, er wird auch per Autocreate angelegt.

Wenn ich nun den einen sduino ausstecke und den anderen in den PC einstecke, dann funktioniert der dispatch nicht mehr. In der Parse Routine des LaCrosse Modul kommt nichts an. (bei allen anderen Modulen funktioniert ein Wechsel problemlos)
Ab und zu funktioniert es nach einem fhem restart wieder. 
Es kommt auch vor, daß ich vor dem restart das angelegte LaCrosse Device vom TX29 löschen muss oder die regexp von der matchlist editieren muss.

Die regexp ist inzwischen recht einfach
"30:LaCrosse" => '^OK.*',

Können evtl die Leerzeichen in der LaCrosse Nachricht Probleme machen?

Mir fehlt ein Ansatz wie ich das Debuggen kann
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Ralf9

Habs gefunden, es liegt an diesem Eintrag, dadurch muss nach einem Wechsel des IODev ein fhem restart gemacht werden, wenn ich dies auskommentiere, funktioniert es auch mit einem anderen IODev
$hash->{FingerprintFn}   = "LaCrosse_Fingerprint";

sub LaCrosse_Fingerprint($$) {
  my ($name, $msg) = @_;

  return ( "", $msg );
}

FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

sash.sc

#486
Zitat von: Ralf9 am 07 Januar 2020, 23:12:40
Dies wird mit der jetzigen Arduino Hardware wahrscheinlich nicht gehen. Mit dem Maple Mini müsste es machbar sein.

Was demnächst gehen müsste, wenn Du nichts senden möchtest, ist per Timer zwischen den EEPROM Speicherbänken umzuschalten.
Wenn die Sensoren nicht so weit weg sind, empfängt der 868 cc1101 auch recht brauchbar die 433 Sensoren, auch durch eine Betondecke.

Wenn Du z.B. auf der Bank 0 eine cc1101 Register konfiguration für 433 MHz und auf Bank 1 eine Register konfiguration für LaCrosse hast,
dann kannst Du dies dann so konfigurieren, daß z.B. für 10 Min die Register konfiguration von Bank 0 und dann für 30 Sek Bank 1 für LaCrosse aktiv ist, und dann wieder Bank 0 ...

Habe von Locutus den maple Mini. Da sind schon 2 cc1101 mit beiden Frequenzen drauf und nem esp-01 als serial wlan bridge. LAN Modul kann man auch noch drauf löten.
Theoretisch wäre die Hardware da, oder?


Gesendet von meinem MI 9 mit Tapatalk
Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

Ralf9

ZitatHabe von Locutus den maple Mini. Da sind schon 2 cc1101 mit beiden Frequenzen drauf und nem esp-01 als serial wlan bridge. LAN Modul kann man auch noch drauf löten.
Theoretisch wäre die Hardware da, oder?
Ja die Hardware sollte ungefähr passen

FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

sash.sc

Cool, fehlt nur noch die Firmware. [emoji6]

Gesendet von meinem MI 9 mit Tapatalk

Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

Ralf9

#489
Hier ist für den Arduino nano , minicul und CUL V3 die Firmware V3.3.4 und  V3.3.5, damit ist auch ein Empfangen und Senden von FSK modulierten Signalen möglich.Es gibt auch 10 EEPROM Speicherbänke in denen die cc1101 Register gespeichert werden können.

Es gibt seit 29.05.22 eine neue Version V3.3.5 es ist dafür mein 00_SIGNALDuino Modul ab v3.4.13-dev_ralf_29.05. notwendig
https://github.com/Ralf9/SIGNALDuino/releases/tag/3.3.5-dev220529

Die aktuelle Version ist V3.3.4-dev211207
https://github.com/Ralf9/SIGNALDuino/releases/tag/3.3.4-dev211207
https://github.com/Ralf9/SIGNALDuino/releases

für den nano mit cc1101
set sduino flash https://github.com/Ralf9/SIGNALDuino/releases/download/3.3.4-dev200914/SIGNALduino_nanoCC1101_3340dev200914.hex
für den minicul
set sduino flash https://github.com/Ralf9/SIGNALDuino/releases/download/3.3.4-dev200914/SIGNALduino_miniCUL_3340dev200914.hex


3.3.4-dev200914 SIGNALduino cc1101 (minicul 868Mhz) (b2) - compiled at Sep ...
3.3.4-dev200914 SIGNALduino cc1101 (b1) - compiled at Sep ...


In der firmware V 3.3.4 gibt es einen neuen Befehl b<0-9>, damit können dann die cc1101 Register zwischen 10 verschiedenen EEPROM Bänken (0000, 0100, 0140, 0180, 01C0,..) umgeschaltet werden.
Mit b? kann die aktuelle Bank abgefragt werden. Wenn mit b<0-9> auf eine nicht initialisierte Bank gewechselt wird, dann kann es noch zu einem Absturz der Firmware kommen.

Mit b<0-9>W wird die Bank umgeschaltet und die BankNr im EEPROM gespeichert.
Edit 12.01.20: Es wird nun durch eine Abfrage verhindet, daß auf eine nicht initialisierte Bank umgeschaltet wird (siehe unten)

Mit e<0-9> wird auf die angegebene Bank ein cc1101 Factoryreset durchgeführt.




Mit der firmware V 3.3.4-dev200914 gibt es die folgende Neuerungen:
-  Es gibt einen neuen Befehl "bs" - Banksummary (siehe Anlage)
-  ccmode=4 zugefügt
-  beim CW Befehl die Bank Kurzbeschreibung zugefügt
-  Bei SlowRF (ASK/OOK) wird beim Sendebefehl das Echo auf 100 Zeichen begrenzt.
-  Wenn eine nicht initialisierte EEPROM Speicherbank ausgewählt wurde, dann wird diese mit den sduino Defaults initialisiert (raw e).



Ab der firmware V 3.3.4.0 dev 200121 gibts ein neues Kommando "CW", damit kann eine folge von cc1101 Registern gesetzt und in die aktuelle EEPROM Speicherbank geschrieben werden.
https://forum.fhem.de/index.php/topic,106594.msg1005067.html#msg1005067

Um z.B. die cc1101 Register vom culw Mode 1 - IT+ 17.241 kbps auf die EEPROM Bank 1,  PCA301 auf Bank 3 und  Kopp Free Kontrol auf Bank 4 zu speichern,

- wird zuerst mit b1 (get sduino raw b1)  die Bank 1 aktiviert, (wenn defaultmässig die Bank 1 verwendet werden soll, dann kann mit b1W die default Banknr im EEPROM gespeichert werden)
wenn die Bank noch nicht initialisiert ist, kommt die folgende Antwort
The Bank 1 was not init, therefore it reseted to sduino defaults (raw e).
Nun werden damit
get sduino raw CW0001,012E,0246,0302,042D,05D4,06FF,0700,0802,0D21,0E65,0F6A,1089,115C,1206,1322,14F8,1556,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D00,3E03,404d,4131,425f,4349,4454,452b,4600
die für den Mode 1 - IT+ notwendigen cc1101 Registeränderungen in die Bank 1 geschrieben und mit 3E03 wird auch gleich die Konfigvariable ccmode auf 3 gesetzt.

- dann wird mit b3 (get sduino raw b3)  die Bank 3 aktiviert, wenn die Bank noch nicht initialisiert ist, dann wird sie automatisch mit den sduino defaults (raw e) initialisiert,
Nun werden damit

get sduino raw CW0001,012E,0246,0307,042D,05D4,06FF,0700,0802,0D21,0E6B,0FD0,1088,110B,1206,1322,14F8,1553,1700,1818,1916,1B43,1C68,1D91,2211,23E9,242A,2500,2611,3D03,3E03,4050,4143,4241,435f,4433,4530,4631,4700

die für PCA301 notwendigen cc1101 Registeränderungen in die Bank 3 geschrieben und mit 3D03 wird auch gleich die Konfigvariable ccN auf 3 und mit 3E03 wird die Konfigvariable ccmode auf 3 gesetzt.

- und mit b4 (get sduino raw b4)  wird die Bank 4 aktiviert, wenn die Bank noch nicht initialisiert ist, dann wird sie automatisch mit den sduino defaults (raw e) initialisiert,
Nun kann mit
get sduino raw CW0001,012E,0206,0304,04AA,0554,060F,07E0,0800,0D21,0E65,0F6A,1097,1183,1216,1363,1547,170C,1829,1936,1C40,1D91,23E9,242A,2500,3D04,3E02,404b,416f,4270,4370,445f,4546,4643,4700
die für Kopp notwendigen cc1101 Registeränderungen in die Bank 4 geschrieben und ccN auf 4 und ccmode auf 2 gesetzt werden.




Bei ccmode sind z.Zt. die folgenden Werte möglich:
0 - normal (OOK)
1 - FIFO auslesen normal, z.B. für Kopp
2 - FIFO auslesen ohne Wiederholungen
3 - FIFO auslesen LaCrosse
4 - FIFO auslesen LaCrosse (selbe Methode wie bei der a-culw)
9 - FIFO auslesen mit Debug Ausgaben

Beim mode 9 ist vor und nach dem Ausgeben die Anzahl der Bytes im FIFO in Klammern angegeben.
M13 bedeutet das marcstate Register = 13



Ich habe auch eine Unschönheit beim Befehl XQ behoben.
Wenn nun mit XQ der Empfang gesperrt  wird, bleibt er auch nach dem Senden gesperrt



Nun werden beim Umschalten auf eine Bank größer 0 die ersten beiden Speicherstellen in der umzuschalteten Bank abgefragt.
In der ersten Speicherstelle muss die Banknummer und in der zweiten Speicherstelle (255 - Banknr) stehen.
z.B. in der Bank 1
0100: 01
0101: FE




Für die FSK und EEPROM Speicherbank unterstützung ist eine angepasste und erweiterte Version der 00_SIGNALduino.pm und die signalduino_protocols.pm notwendig:
https://github.com/Ralf9/RFFHEM/issues/4
Siehe auch hier:
https://forum.fhem.de/index.php/topic,106594.msg1004463.html#msg1004463


Linkliste

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Ralf9

Zitat von: sash.sc am 08 Januar 2020, 06:19:20
Habe von Locutus den maple Mini. Da sind schon 2 cc1101 mit beiden Frequenzen drauf und nem esp-01 als serial wlan bridge. LAN Modul kann man auch noch drauf löten.
Theoretisch wäre die Hardware da, oder?

Eine Einschränkung wirds geben, ich habe nicht vor es so einzubauen, daß auf beiden cc1101 Modulen OOK/ASK (slowrf Modus vom cul) empfangen werden kann. Dies ist mir viel zu aufwändig. Ist dies beim Maple cul möglich?
D.h. es wird nicht möglich sein, FS20 oder die WH1080 auf  868MHz und gleichzeitig 433 MHz Sensoren zu empfangen.
Auf dem zweiten cc1101 wird nur der native Mode des cul möglich sein.
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

sash.sc

Man kann für jedes Modul einen Modus einstellen. 433 slowrf und 868 habe ich für Homematic. Jedes folgemodul wird als separates device (STACKABLE_CC) angelegt

Gesendet von meinem MI 9 mit Tapatalk

Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

Ralf9

@RaspII
Mittlerweile funktioniert auch das einfache Senden über den FIFO.

Mir ist aber nicht klar was das beim kopp_fc in der "kopp-fc.c" mit dem SingleBlkOnly auf sich hat
if(in[1] == 's') SingleBlkOnly=1;
In welchen Fällen ist momentan "SingleBlkOnly=0"?
Im KOPP_FC Modul beginnen momentan alle gesendeten Nachrichten mit "ks"

FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

RaspII

#493
Hi
Ich schreibe dir heute Abend eine ausführliche Antwort.

Ich habe aber auch noch eine Frage an Euch:
Hat schon jemand den Fifo Mode mit ASK/OOK genutzt?


Hintergrund:
Kopp V1 sendet via OOK
RaspII

RaspII

Die aktuellen Kopp Module haben zwei Modi
1. kurzer Tastendruck
damit schaltet  man Devices ein, aus oder toggelt den Zustand.

2. langer Tastendruck (der Tastencode ist dann um 0x80 höher)
damit kann man z.B. Dimmer steuern, d.h. solange die Taste gedrückt wird ändert sich der Zustand.

Die alten KoppV1 Module haben tatsächlich während dem langen Tastendruck dauern den selben Code gesendet.
In den neuen Modulen ist das anders gelöst.
Wird ein langer Tastendruck erkannt wird eine Art "Startcode" gesendet, nach loslassen der Taste ein Endcode, natürlich jeweils ein kompletter Block.

Wenn man jetzt noch weiß, dass ich die Software über einen längeren Zeitraum entwickelt hat, versteht man eher, das ich:

  • Anfangs die Module aus FHEM heraus im reinem RAW Mode also ohne KOPP_FC bedient habe
  • Nachdem ich dann FHEM besser verstanden habe und mich auch an Perl herangetraut habe sind immer mehr Funktionalitäten in FHEM reingewandert (z.B. Kennt FHEM jetzt die wichtigsten Kopp Aktoren)


Fazit:
"kt" wird von FHEM nicht genutzt, möchte man aber z.B. neue Module ohne FHEM Implementierung bedienen kann man diesen Befehl im RAW Mode immer noch nutzen
Alles klar?

RaspII