FSK mit dem SIGNALDuino

Ralf9 · 12 November 2022, 22:03:28

Bitte ersetze in der lib/signalduino_protocols.pm bei der Protokoll ID 200 die folgenden Einträge. Sie werden erst nach einem fhem neustart aktiv

Code Auswählen

				one             => [2,-1],
				zero            => [1,-2],
				start           => [-3],
				end             => [3],
				clockabs        => 160,

Ein "set SDuino868 sendMsg P200#0xdbf860200009#R50" ergibt dann:

Code Auswählen

SR;R=50;P0=-480;P1=320;P2=-160;P3=160;P4=-320;P5=480;D=01212341212341212121212121234343434121234343434343434123434343434343434343434343434343434123434125;

In Deinem log war nur eine brauchbare Nachricht dabei, die anderen sind zu kurz:

Code Auswählen

MU;P0=-173;P1=325;P3=147;P4=-332;P5=476;P6=-480;CP=3;R=245;D=1034341056101034101034101010101010103434343410103434343434343410343434343434343434343434343434343410343410561010341010341010101010101034343434101034343434343434103434343434343434343434343434343434103434105;

DOCa Cola · 13 November 2022, 14:35:13

Ich habe die Änderungen durchgeführt. Im Universal Radio Hacker sieht das Signal jetzt gut aus von den Laufzeiten. Ich konnte jetzt auch den Honeywell Funkgong mit einem vom Signalduino erzeugten Signal pairen. Super

Als Notiz für diejenigen, die einen virtuellen Sender haben wollen, reicht es hier die Kennung zu ändern. Vereinfacht ändert man dazu einfach die ersten 2 Bytes (die ausführlichere Spezifikation findet man unter https://github.com/klohner/honeywell-wireless-doorbell). Mit manchen von mir getesteten Kennungen wollte sich die die Türklingel allerdings nicht pairen. Das Muster ist mir nicht ganz klar, aber man probiert halt rum bis die Klingel zufrieden ist.

Code Auswählen


P200#0xXXXX60200009#R50
       ^^^^
       Kennung

Jetzt fehlt mir nur noch der umgekehrte Weg. Wie bekomme ich ein Event in FHEM, wenn der Signalduino vom Funkgong ein eingehendes Klingelsignal erhält? Im Log ist es ja wunderbar aufgeführt, aber wie komme ich da nun als Event ran?

Ralf9 · 13 November 2022, 15:21:23

Ich hab für Honeywell ActivLink ein neues Thema angelegt
https://forum.fhem.de/index.php/topic,130271.0.html

weini · 12 Februar 2023, 20:40:59

Mein LaCrosse GW gibt langsam den Geist auf, deshalb möchte ich einen nanoCUL 868 mit SIGNALDuino gerne als alternatives GW nutzen.

Soweit hat das auch alles ganz gut geklappt: Umgeflasht, Attribute eingestellt, Protokolle ausgewählt usw.
Das Device sieht so aus:

Code Auswählen

Internals:
   CFGFN      
   Clients    :CUL_EM:CUL_FHTTK:CUL_TCM97001:CUL_TX:CUL_WS:Dooya:FHT:FLAMINGO:FS10:FS20: :Fernotron:Hideki:IT:KOPP_FC:LaCrosse:OREGON:PCA301:RFXX10REC:Revolt:SD_AS:SD_Rojaflex: :SD_BELL:SD_GT:SD_Keeloq:SD_RSL:SD_UT:SD_WS07:SD_WS09:SD_WS:SD_WS_Maverick:SOMFY: :Siro:SIGNALduino_un:
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0@57600
   DMSG       OK 9 41 1 2 98 106
   DevState   initialized
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0@57600
   FD         40
   FLASH_RESULT ERROR: avrdude exited with error
   FUUID      63e8dc74-f33f-b8ff-f9ae-f76a1e31c6ae2c4f
   LASTDMSG   OK 9 41 1 2 98 106
   LASTDMSGID 100
   MSGCNT     3594
   NAME       sduino868
   NR         842
   PARTIAL    
   RAWMSG     MN;D=9A40106A2E;R=35;
   RSSI       -56.5
   STATE      opened
   TIME       1676230403.87769
   TYPE       SIGNALduino
   cc1101_available 1
   eventCount 182
   sendworking 0
   version    V 3.5.0-dev+20210808 SIGNALduino cc1101 (chip CC1101) - compiled at Aug  7 2021 22:44:01
   versionProtocols 1.49
   versionmodul 3.5.5+20230128
   DoubleMsgIDs:
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
     11:SD_WS09 ^P9#F[A-Fa-f0-9]+
     12:SD_WS   ^W\d+x{0,1}#.*
     13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
     14:Dooya   ^P16#[A-Fa-f0-9]+
     15:SOMFY   ^Ys[0-9A-F]+
     16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
     17:SD_UT   ^P(?:14|20|24|26|29|30|34|46|56|68|69|76|78|81|83|86|90|91|91.1|92|93|95|97|99|104|105|114|118|121)#.*
     18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
     19:CUL_WS  ^K[A-Fa-f0-9]{5,}
     1:IT       ^i......
     20:Revolt  ^r[A-Fa-f0-9]{22}
     21:FS10    ^P61#[A-F0-9]+
     22:Siro    ^P72#[A-Fa-f0-9]+
     23:FHT     ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     24:FS20    ^81..(04|0c)..0101a001
     25:CUL_EM  ^E0.................
     26:Fernotron ^P82#.*
     27:SD_BELL ^P(?:15|32|41|42|57|79|96|98|112)#.*
     28:SD_Keeloq ^P(?:87|88)#.*
     29:SD_GT   ^P49#[A-Fa-f0-9]+
     2:CUL_TCM97001 ^s[A-Fa-f0-9]+
     30:LaCrosse ^(\S+\s+9 |OK\sWS\s)
     31:KOPP_FC ^kr\w{18,}
     32:PCA301  ^\S+\s+24
     33:SD_Rojaflex ^P109#[A-Fa-f0-9]+
     3:SD_RSL   ^P1#[A-Fa-f0-9]{8}
     4:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     5:CUL_TX   ^TX..........
     6:SD_AS    ^P2#[A-Fa-f0-9]{7,8}
     7:Hideki   ^P12#75[A-F0-9]+
     9:CUL_FHTTK ^T[A-F0-9]{8}
     X:SIGNALduino_un ^[u]\d+#.*
   QUEUE:
     P
   READINGS:
     2023-02-12 15:02:23   cc1101_config   Freq: 868.300 MHz, Bandwidth: 203 kHz, rAmpl: 33 dB, sens: 8 dB, DataRate: 17.26 kBaud
     2023-02-12 15:02:23   cc1101_config_ext Modulation: 2-FSK, Syncmod: 16/16 sync word bits detected, Deviation: 88.87 kHz
     2023-02-12 15:02:24   cc1101_patable  C3E = 00 67 00 00 00 00 00 00 => -5_dBm
     2023-02-12 20:32:27   ping            OK
     2023-02-12 15:02:22   state           opened
   additionalSets:
     flash      3.5.0,3.5.0-dev+20210808,3.5.0-dev+20210623,3.4.0,3.4.0-dev+20200711,3.4.0-dev+20200216,3.3.1
   helper:
     avrdudecmd avrdude -c arduino -b 57600 -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -p atmega328p -vv -U flash:w:FHEM/firmware/SIGNALDuino_nanocc1101_3.5.0-dev+20210808.hex 2>./log/SIGNALduino-Flash.log || avrdude -c arduino -b 115200 -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -p atmega328p -vv -U flash:w:FHEM/firmware/SIGNALDuino_nanocc1101_3.5.0-dev+20210808.hex 2>./log/SIGNALduino-Flash.log
     avrdudelogs flashing Arduino sduino868
hex file: FHEM/firmware/SIGNALDuino_nanocc1101_3.5.0-dev+20210808.hex
port: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
command: avrdude -c arduino -b 57600 -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -p atmega328p -vv -U flash:w:FHEM/firmware/SIGNALDuino_nanocc1101_3.5.0-dev+20210808.hex 2>[LOGFILE] || avrdude -c arduino -b 115200 -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -p atmega328p -vv -U flash:w:FHEM/firmware/SIGNALDuino_nanocc1101_3.5.0-dev+20210808.hex 2>[LOGFILE]

sduino868 closed
--- AVRDUDE ---------------------------------------------------------------------------------

avrdude: Version 6.3-20171130
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/etc/avrdude.conf"
         User configuration file is "/opt/fhem/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x18
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x80
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0xe6
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x98
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0xf8
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x98
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x9e
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x18
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x06

avrdude done.  Thank you.

--- AVRDUDE ---------------------------------------------------------------------------------

sduino868 reopen started

   keepalive:
     ok         0
     retry      1
   mcIdList:
   mnIdList:
     100
     103
     107.1
   msIdList:
     74.1
   muIdList:
     74
   ucCmd:
     cmd        ping
     timenow    1676230407.77895
Attributes:
   addvaltrigger 1
   cc1101_frequency 868
   devStateIcon opened:usb@green closed:usb@yellow disconnected:usb@red
   group      CUL
   hardware   nanoCC1101
   longids    1
   rfmode     Lacrosse_mode1
   sortby     51
   updateChannelFW testing
   whitelist_IDs 74,74.1,100,103,107.1

Im Liste sehe ich einen Flash-Error. Aus meiner Sicht hat der Flash aber funktioniert... $:-\$

Ich habe 2 Temperaturfühler auf Basis LaCrosse im Einsatz:

Beide sollten laut Doku/Hilfe mit Lacrosse_mode1 funktionieren. Tatsächlich bekomme ich aber keine Daten vom 30.3144.IT empfangen, der TX29.IT funktioniert dagegen einwandfrei.
Der 30.3144.IT funktioniert an meinem alten LaCrosse GW problemlos. Auch ein kurzer Test mit der nanoCUL FW mit aktivierten LaCrosse-2-HMS Emulation hat soweit funktioniert. Nur mit dem SIGNALduino mag er nicht.

Habt ihr noch Tipps, worauf ich achten könnte oder was anders einzustellen ist?

Ralf9 · 12 Februar 2023, 20:57:59

Kommt mit sduino verbose 4 nichts vom 30.3144.IT?

Die RAWMSG sehen ungefähr so aus: MN;D=9A40106A2E...

Du kannst mal die Frequenz ein klein wenig in 0.05 MHz schritten ändern

Gruß Ralf

weini · 12 Februar 2023, 21:16:15

Guter Tipp, danke!

verbose=4 liefert mir folgendes:

Code Auswählen


2023.02.12 21:13:47.630 4: sduino868: Parse_MN, Found 2-FSK Protocol id 100 -> Lacrosse mode 1 with match (?^:^9)
2023.02.12 21:13:47.649 4: sduino868: Parse_MN, Found 2-FSK Protocol id 103 -> Lacrosse mode 2 with match (?^:^9)
2023.02.12 21:13:47.649 4: sduino868: Dispatch, OK 9 41 1 2 97 106, Dropped due to short time or equal msg
2023.02.12 21:13:47.649 4: sduino868: Parse_MN, Error! id 107.1 msg=9A40096A83, message is to short
2023.02.12 21:13:56.262 4: sduino868: Read, msg: MN;D=9A40096A83;R=31;
2023.02.12 21:13:56.264 4: sduino868: Parse_MN, Found 2-FSK Protocol id 100 -> Lacrosse mode 1 with match (?^:^9)
2023.02.12 21:13:56.304 4: sduino868: Parse_MN, Found 2-FSK Protocol id 103 -> Lacrosse mode 2 with match (?^:^9)
2023.02.12 21:13:56.305 4: sduino868: Dispatch, OK 9 41 1 2 97 106, Dropped due to short time or equal msg
2023.02.12 21:13:56.305 4: sduino868: Parse_MN, Error! id 107.1 msg=9A40096A83, message is to short
2023.02.12 21:14:04.910 4: sduino868: Read, msg: MN;D=9A40096A83;R=31;
2023.02.12 21:14:04.911 4: sduino868: Parse_MN, Found 2-FSK Protocol id 100 -> Lacrosse mode 1 with match (?^:^9)
2023.02.12 21:14:04.947 4: sduino868: Parse_MN, Found 2-FSK Protocol id 103 -> Lacrosse mode 2 with match (?^:^9)
2023.02.12 21:14:04.947 4: sduino868: Dispatch, OK 9 41 1 2 97 106, Dropped due to short time or equal msg
2023.02.12 21:14:04.948 4: sduino868: Parse_MN, Error! id 107.1 msg=9A40096A83, message is to short
2023.02.12 21:14:13.662 4: sduino868: Read, msg: MN;D=9A40096A83;R=32;
2023.02.12 21:14:13.663 4: sduino868: Parse_MN, Found 2-FSK Protocol id 100 -> Lacrosse mode 1 with match (?^:^9)
2023.02.12 21:14:13.679 4: sduino868: Parse_MN, Found 2-FSK Protocol id 103 -> Lacrosse mode 2 with match (?^:^9)
2023.02.12 21:14:13.680 4: sduino868: Dispatch, OK 9 41 1 2 97 106, Dropped due to short time or equal msg
2023.02.12 21:14:13.680 4: sduino868: Parse_MN, Error! id 107.1 msg=9A40096A83, message is to short

Ich spiele mal mit der Frequenz

weini · 12 Februar 2023, 23:10:00

Zwischen 868.250 und 868.350 kann ich den TX29-IT stabil empfangen, für den 30.3144.IT bekomme ich nur die Fehler wie oben angegeben.
Unter bzw. über den Schwellwerten verliere ich beide Sensoren.

VG, weini

Ralf9 · 12 Februar 2023, 23:31:05

Was ist der 30.3144.IT für ein Sensor, kann der auch Luftfeuchtigkeit?

Wenn ich dies "OK 9 41 1 2 97 106" per Dispatch zum LaCrosse Modul schicke, bekomme ich:

Code Auswählen

2023-02-12 23:24:08.953 LaCrosse LaCrosse_29 battery: ok
2023-02-12 23:24:08.953 LaCrosse LaCrosse_29 temperature: -39.1

weini · 13 Februar 2023, 06:54:12

Aha!

Das ist der TX29-IT. Der hat nur Temperatur und Batterie und ist als Helligkeitssensor umgebaut, weshalb er in der Nacht den recht tiefen Temperaturwert zeigt. Das ist also genau der Sensor, wo der Empfang gut klappt. Insofern ist die "Parse_MN, Error!" Meldung wohl nicht so ganz ernst zu nehmen.

Nun habe ich über Nacht auch ein paar wenige Lebenszeichen vom 30.3144.IT bekommen:

Code Auswählen

2023.02.13 05:58:46.496 4: sduino868: Read, msg: MN;D=96843050F0;R=19;
2023.02.13 05:58:46.497 4: sduino868: Parse_MN, Found 2-FSK Protocol id 100 -> Lacrosse mode 1 with match (?^:^9)
2023.02.13 05:58:46.520 4: sduino868: Parse_MN, Found 2-FSK Protocol id 103 -> Lacrosse mode 2 with match (?^:^9)
2023.02.13 05:58:46.520 4: sduino868: Dispatch, OK 9 26 1 4 6 80, Dropped due to short time or equal msg
2023.02.13 05:58:46.520 4: sduino868: Parse_MN, Error! id 107.1 msg=96843050F0, message is to short

So alle 2-3 Stunden kommt mal ein Funktelegramm durch.

Ich spiele jetzt nochmal mit der Frequenz rum. Gestern hatte ich immer nur kurz getestet und sofort weiter verändert, wenn ich die Meldungen für den TX29-IT bekommen hatte.

Ralf9 · 13 Februar 2023, 11:39:16

Code Auswählen

2023.02.13 05:58:46.520 4: sduino868: Parse_MN, Error! id 107.1 msg=96843050F0, message is to short

ZitatInsofern ist die "Parse_MN, Error!" Meldung wohl nicht so ganz ernst zu nehmen.

Dies ist etwas unglücklich programmiert, dies ist keine Fehlermeldung sondern nur ein Hinweis, daß die ID 107.1 bei diesem rfmode nicht verarbeitet werden kann.

Da Du nur Lacrosse mode 1 Sensoren hast, ist es ausreichend wenn Du in der whitelist nur die ID 100 einträgst.
Dies geht auch in dem " Protocollist Overviev" Fenster.

weini · 13 Februar 2023, 14:49:21

Ok, habe das LaCrosse 2 Protokoll deaktiviert, damit ist die "Parse_MN, Error!" Meldung weg.

Leider wird es mit dem 30.3144.IT nicht besser: Abweichende Frequenzen bringen nichts, ab ehesten kommt noch mit 868.300 etwas durch.
Spannend finde ich dabei, dass die RSSI Werte im LaCrosse Device mit sduino868_RSSI=-74.5 eigentlich gut sind. Nur kommt eben so gut wie nichts an.

Auszug der Internals vom Temperatur Device:

Code Auswählen


lcg_LaCrosse_MSGCNT	76
lcg_LaCrosse_TIME	2023-02-13 09:10:28
previousH	72
previousT	4.9
sduino868_DMSG	OK 9 36 1 4 25 72
sduino868_MSGCNT	10
sduino868_Protocol_ID	100
sduino868_RAWMSG	MN;D=99044948A9;R=255;
sduino868_RSSI	-74.5
sduino868_TIME	2023-02-13 14:23:38

Mit dem "echten" LaCrosse GW kommen die Meldungen dagegen schnell und zahlreich.

Im Forum habe ich auch keine Posts zu 30.3144.IT mit SIGNALDuino gefunden.
Habe schon überlegt, ob ich mir einen zweiten 30.3144.IT nachbestelle um zu testen, ob meiner ggf. eine Macke hat. Die zugehörige Wetterstation empfängt die Daten aber recht kontinuierlich. Bin etwas ratlos...

Ralf9 · 13 Februar 2023, 15:23:25

Werden vom 30.3144.IT fehlerhafte oder nur sehr wenige rawmsg empfangen.
Es sollte normalerweise ca alle 10sec was empfangen werden.

Welche rawmsg werden empfangen, wenn Du vom TX29-IT die Batterien raus nimmst?

weini · 13 Februar 2023, 15:36:04

Sehe ich die empfangenen RAWMSG im Log mit verbose 4?

Da kommt nur alle paar Stunden etwas durch.
Als ich auf dem 868er nanoCUL die culfw mit LaCrosse Empfang https://forum.fhem.de/index.php/topic,36565.msg702663.html#msg702663 drauf hatte, da habe ich die Telegramme im 10 Sekunden Takt empfangen. Auch über mein altes LaCrosse GW kommen die Daten in ungefähr dieser Frequenz rein.

Wenn ich aus dem TX29-IT die Batterie rausnehme, dann bleibt bei verbose 4 das im Log übrig:

Code Auswählen


2023.02.13 15:31:39.573 4: sduino868: KeepAlive, ok, retry = 0
2023.02.13 15:32:39.663 4: sduino868: KeepAlive, not ok, retry = 1 -> get ping
2023.02.13 15:32:39.711 4: sduino868: HandleWriteQueue, called
2023.02.13 15:32:39.711 4: sduino868: SendFromQueue, called
2023.02.13 15:32:39.729 4: sduino868: Read, msg: OK
2023.02.13 15:32:40.023 4: sduino868: HandleWriteQueue, called
2023.02.13 15:32:40.023 4: sduino868: HandleWriteQueue, nothing to send, stopping timer
2023.02.13 15:33:39.796 4: sduino868: KeepAlive, ok, retry = 0

Ralf9 · 13 Februar 2023, 17:10:43

was bekommst Du mit "get ccconf"?

Ich bekomme:

Code Auswählen

ccconf: freq:868.300MHz bWidth:203KHz rAmpl:33dB sens:8dB (DataRate:17257.69Baud)

Modulation:2-FSK (SYNC_MODE:16/16 + carrier-sense above threshold) DEVIATN:88.867kHz

ZitatSehe ich die empfangenen RAWMSG im Log mit verbose 4?

ja

weini · 13 Februar 2023, 17:27:25

Hier mein get cconf:

Code Auswählen


ccconf: Freq: 868.300 MHz, Bandwidth: 203 kHz, rAmpl: 33 dB, sens: 8 dB, DataRate: 17.26 kBaud, Modulation: 2-FSK, Syncmod: 16/16 sync word bits detected, Deviation: 88.87 kHz

Syntaktisch leicht abweichend, semantisch aber gleichbedeutend, oder?
Ist trotzdem interessant, warum das nicht identisch ist.

Ich habe folgende Repositories eingebunden:

Code Auswählen


http://fhem.de/fhemupdate/controls_fhem.txt
https://raw.githubusercontent.com/sw-home/FHEM-HomeConnect/master/controls_homeconnect.txt
https://raw.githubusercontent.com/verybadsoldier/esp_rgbww_fhemmodule/master/controls_espledcontroller.txt
https://raw.githubusercontent.com/uniqueck/fhem-abfall/master/controls_fhemabfall.txt
https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master/controls_signalduino.txt

Gibt es da eine Präferenz? Ist die Reihenfolge relevant, wenn ein Modul von mehreren Repositories angeboten wird?