Signalduino Version 3.3.1 / 3.3.2 / 3.3.3-dev

[heigu]

Hallo Ralf9,

danke für die Erklärung und Anweisungen. Ich werde in den nächsten Tagen Raw-Nachrichten sammeln und unter den angegeben Link posten.

Gruß,
heigu

[plin]

Hi,

Ich habe mir drei neue Funkthermometer (Funk-Außensensor für Wetterstation FWS-70, https://www.pearl.de/a-NX6876-3041.shtml) von Pearl besorgt. Die werden prinzipiell als SD_WS07_TH Devices erkannt. Diese Sensoren liefern aber de facto nur Temperaturen. Die gesendeten Humidity-Werte springen wild hin und her und gehen auch schon mal in den Bereich > 100. Ist die Humidity >100 verwirft das Modul 14_SD_WS07.pm beide Messwerte. Die korrekt gemessene Temperatur kommt nicht durch. Das führt dazu, dass nur sporadisch Temperaturen erfasst und angezeigt werden.

Ich benötige eine Möglichkeit, um die Behandlung der Humitity komplett auszuschalten, damit die Prüfung ab Code-Zeile 198ff. nicht mehr zieht.

VG Peter

P.S. Die Voranalyse ist hier https://forum.fhem.de/index.php/topic,113600.0.html zu finden.

[HomeAuto_User]

Hallo Peter,
es wäre sehr hilfreich hierfür ein Issues https://github.com/RFD-FHEM/RFFHEM/issues zu eröffnen.
Das ganze Problem liegt in der Vielfalt der Sensoren.

Du müsstest eine Messreihe starten mit Werten um es nachvollziehen zu können.
Das Modul betreut derzeit Sidey und Elektron-bbs. Da sollte man versuchen auch Ihnen das Problem weiter zu tragen an der Entwicklerebene anstatt hier im Forum eine Lösung zu erarbeiten lassen welche vermutlich nicht in das originale Modul kommt.

Liebe Grüße Marco

[plin]

ok, Issue ist unter https://github.com/RFD-FHEM/RFFHEM/issues/888 eröffnet

[Ralf9]

Ich habe mir drei neue Funkthermometer (Funk-Außensensor für Wetterstation FWS-70, https://www.pearl.de/a-NX6876-3041.shtml) von Pearl besorgt. Die werden prinzipiell als SD_WS07_TH Devices erkannt. Diese Sensoren liefern aber de facto nur Temperaturen. Die gesendeten Humidity-Werte springen wild hin und her und gehen auch schon mal in den Bereich > 100. Ist die Humidity >100 verwirft das Modul 14_SD_WS07.pm beide Messwerte. Die korrekt gemessene Temperatur kommt nicht durch. Das führt dazu, dass nur sporadisch Temperaturen erfasst und angezeigt werden.

Ich benötige eine Möglichkeit, um die Behandlung der Humitity komplett auszuschalten, damit die Prüfung ab Code-Zeile 198ff. nicht mehr zieht.

Ich habe mir auch mal Gedanken darüber gemacht.

Eine Möglichkeit wäre, es so wie beim 14_CUL_TCM97001 Modul über ein Attribut model zu machen. Wenn kein Attribut model definiert ist, dann wird es automatisch angelegt.
Wurde das model falsch erkannt, dann kann das richtige Attribut model gewählt werden.

Damit die bisherigen Definitionen noch ohne Model funktionieren und mit überschaubarem Aufwand geprüft werden kann ob es das Attribut model gibt,
ist eine neuer DEF Aufbau sinnvoll.

DEF:
seither z.B.
SD_WS07_TH_2
SD_WS07_TH_A52
SD_WS07_T_2
neu
SD_WS07_2
SD_WS07_A52

Bei shortIDs gibts die Einschränkung, daß dies nur funktioniert, wenn für den Kanal nur 2 Bit ausgewertet werden, dies dürfte aber keine Rolle spielen, da bis jetzt noch keine Sensoren mit mehr als 3 Kanälen bekannt sind.

In der parse Routine muss dann geprüft werden ob der Sensor mit alter oder neuer DEF existiert. Ist er mit der neuen DEF angelegt, dann wird das Attribut model verwendet

Gruß Ralf

[elektron-bbs]

DEF:
seither z.B.
SD_WS07_TH_2
SD_WS07_TH_A52
SD_WS07_T_2
neu
SD_WS07_2
SD_WS07_A52

Das hätte dann aber wieder den Nachteil, das zwei Sensoren mit gleichem Kanal bzw. Ident, einer mit und einer ohne Feuchte, dann im gleichen Device landen.
Ich hatte diesen Effekt gerade mit LaCrosse-Sensoren.

[Ralf9]

Ohne Kompromisse wird es nicht gehen, die Module CUL_TCM97001, CUL_WS und CUL_TX machen es genauso.

Eine alternative wäre den DEF Aufbau bei zubehalten und ein Attribut "overwriteModel" zu verwenden.
Wenn z.B. ein Sensor falsch als als "SD_WS07_TH_2" erkannt wurde und dann per Attribut in ein Model ohne "Hum" geändert werden soll, dann sollte auch die DEF nach "SD_WS07_T_2" geändert werden.

[Ralf9]

Ich habe hier einen Fix für Somfy gepostet, es wäre schön, wenn er auch ins offizielle Signalduino Modul übernommen werden könnte
https://forum.fhem.de/index.php/topic,72173.msg1079937.html#msg1079937

Damit wird die Erkennung der Nachrichten der Somfy Fernbedienungen deutlich verbessert.
Der Fix ergänzt fehlende Bits am Anfang, siehe auch hier
https://forum.fhem.de/index.php/topic,72173.msg1075881.html#msg1075881

Hier sind einige Beispiele:

Code Auswählen Erweitern

MC;LL=-1281;LH=1282;SL=-635;SH=639;D=04747459CBF22;C=639;L=52;

2020.08.23 22:14:03.090 4 : sduinoD: Somfy bitdata:      0000010001110100011101000101100111001011111100100010 (52)
2020.08.23 22:14:03.090 4 : sduinoD: Somfy bitdata: _10100000010001110100011101000101100111001011111100100010 (56). 1010 am Anfang zugefuegt
2020.08.23 22:14:03.090 5 : sduinoD: dispatch YsA04747459CBF22

Code Auswählen Erweitern

MC;LL=-1292;LH=1267;SL=-640;SH=638;D=811D1D1672FC88;C=639;L=54;

2020.09.17 18:55:36.493 4 : sduinoD: Somfy bitdata:   10000001000111010001110100010110011100101111110010001000 (54)
2020.09.17 18:55:36.493 4 : sduinoD: Somfy bitdata: 10100000010001110100011101000101100111001011111100100010 (56). 1010 am Anfang zugefuegt
2020.09.17 18:55:36.493 5 : sduinoD: dispatch YsA04747459CBF22

Code Auswählen Erweitern

MC;LL=-1327;LH=1243;SL=-683;SH=583;D=52C3C5C5BED8CC8;C=639;L=57;

2020.08.14 23:32:32 4 : sduino: SomfyRTS, bitdata: 010100101100001111000101110001011011111011011000110011001000 (57)
2020.08.14 23:32:32 4 : sduino: SomfyRTS, bitdata: _10100101100001111000101110001011011111011011000110011001 (56). Bit am Anfang entfernt
2020.08.14 23:32:32 5 : sduino: dispatch YsA5878B8B7DB199

Code Auswählen Erweitern

MC;LL=-1317;LH=1237;SL=-689;SH=594;D=545ADCCD365044;C=639;L=56;

2020.09.17 19:05:36.764 4 : sduinoD: Somfy bitdata: 01010100010110101101110011001101001101100101000001000100 (56)
2020.09.17 19:05:36.764 4 : sduinoD: Somfy bitdata: _10101000101101011011100110011010011011001010000010001000 (56). Bit am Anfang entfernt
2020.09.17 19:05:36.764 5 : sduinoD: dispatch YsA8B5B99A6CA088


Gruß Ralf

[yoda_gh]

Hallo zusammen!

Dumme Frage: wie läuft denn eigentlich aktuell die SIGNALduino-Entwicklung? Gibt es hier noch einen "Haupt"-Thread für die Weiterentwicklung von  https://github.com/RFD-FHEM/RFFHEM/? Der Link dort verweist ja auf einen Foren-Thread, der nicht mehr benutzt werden soll und hierher verweist, aber der hier scheint auch veraltet zu sein?

Soweit ich sehe, gibt es Threads für den Fork von Ralf9 (FSK) und diverse Detail-Threads für einzelne Probleme/Geräte, aber was generisches für die "Upstream"-SIGNALduino-Version habe ich grad nicht gefunden.

Ich habe einen kleinen Patch entwickelt, der die Checksum für Revolt auswertet und ungültige Nachrichten verwirft, um falsche autocreates zu vermeiden - aktuell gegen die Version auf svn.fhem.de - und dort würde ich den Patch gerne irgendwann sehen. Was wäre das generische Vorgehen dafür? Ein PR gegen https://github.com/RFD-FHEM/RFFHEM/?

[yoda_gh]

Hier schon mal vorab der Patch, auch damit ich ihn nicht verliere.

Habe jetzt auch schon mal einen Draft-PR angelegt: https://github.com/RFD-FHEM/RFFHEM/pull/956

[yoda_gh]

Und gleich noch eine Frage: in https://wiki.fhem.de/wiki/SIGNALduino#FHEM-Modul_laden scheint mir die Beschreibung für die verschiedenen Branches etwas durcheinander zu gehen.

Dort wird folgendes empfohlen:

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master/controls_signalduino.txt

Und um "dauerhaft die developer Version" zu bekommen:

Code Auswählen Erweitern

update add https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r34/controls_signalduino.txt

Sollte es da nicht auch "master" heißen?

Und gibt es einen guten Grund, "normalen" Usern überhaupt das Update von Github zu empfehlen - oder sollte das "update all" nur optional für die sein, die z.B. FSK wollen? Bzw. ist es überhaupt eine gute Idee, nur einmalig die Version von "master" zu verwenden und dann später auf die Version von svn.fhem.de zurückzufallen?

Ich wollte das Wiki nicht einfach ändern, falls es gute Gründe für den aktuellen Text gibt, lasst mich das bitte wissen, sonst baue ich das gerne um.

[Sidey]

Danke für den Hinweis im Wiki, das hatte ich nicht aktualisiert.

Das Update vom github kann man immer dann machen, wenn man eine neue Funktion benötigt.
Die SVN Version hinkt da immer etwas hinterher bis neue Features ausgereift sind. Wie aktuell z.B. FSK.

Güße Sidey

[yoda_gh]

Danke für den Hinweis im Wiki, das hatte ich nicht aktualisiert.

Das Update vom github kann man immer dann machen, wenn man eine neue Funktion benötigt.
Die SVN Version hinkt da immer etwas hinterher bis neue Features ausgereift sind. Wie aktuell z.B. FSK.

Güße Sidey

Ok, danke für die Antwort und Erklärung! Ich habe es nochmal leicht überarbeitet, um die "optionalen" Schritte (also das Update auf die Github-Version) klarer abzutrennen und außerdem habe ich eine generelle Empfehlung für "update add" reingepackt, sonst überschreibt das nächste "update" ja gleich wieder die Github-Version (gerade getestet). Hoffe, das passt!

[alexmetz]

Entschuldigung, dass ich hier reinplatze. Ich habe das Problem, dass ich der wiki gefolgt bin und das github repository hinzugefügt habe. Jetzt kommt "cannot load module 00_SIGNALduino.pm".
Im Log steht Folgendes:

Code Auswählen Erweitern

2021.05.18 23:45:59 0: Attempt to reload lib/SD_Protocols.pm aborted.
Compilation failed in require at ./FHEM/00_SIGNALduino.pm line 30.
BEGIN failed--compilation aborted at ./FHEM/00_SIGNALduino.pm line 30.
Ich habe jetzt hier im Forum in einem Thread aus 2017 gefunden, dass das an dem github liegt und wollte zurück auf das fhem-svn-repositors. Also hab ich mit "update delete ..." das github wieder rausgeschmissen. Ein update sagt mir nun aber "nothing to do". Daher habe ich manuell die Dateien 00_SIGNALduino.pm, SD_Protocols.pm und SD_ProtocolData.pm aus dem svn repositors in meine FHEM-Installation kopiert, Rechte kontrolliert. Aber der Fehler geht nicht weg. Hatte bisher nie einen SIGNALduino und wollte ihn erstmalige einbinden.

Wäre für Eure Hilfe sehr dankbar!
Alex.

UPDATE:
habe vor dem "rumspielen" natürlich ein backup gemacht und das jetzt komplett wieder eingespielt, anschließend ein update aus dem fhem-svn gemacht und jetzt gehts wieder.

[trixer]

Mahlzeit,
da ich aktuell Probleme mit SD_WS_TH Temperetursensoren habe und auch (für ich) unerklärlicherweise das Autocreate von Signalduino Komponenten nicht mehr funktioniert, habe ich gestern Abend ein Update all gemacht:

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master/controls_signalduino.txt

Seitdem war der Signalduino-Stick in FHEM nicht mehr vorhanden. Grund:

ERROR:
Cannot load module SIGNALduino

Auf die Schnelle habe ich nun die 00_SIGNALduino.pm rückgesichert, bin jetzt aber mit folgender alten Version unterwegs:

Code Auswählen Erweitern

version: V 3.3.1 SIGNALduino cc1101 (433 Mhz ) - compiled at Dec 3 2019 19:41:55


Da ich in Kürze auch noch Somfy-Motoren einbinden möchte, würde ich gern vorher noch aktualisieren.
Die genannte Problematik gab es in 2017 auch schon mal, scheint dann aber behoben worden zu sein.
Heißt es nun Geduld bis zur erneuten Behebung oder sollte ich besser eine alternative Quelle einbinden?

Danke & Gruß
Mark

Hier noch die list Ausgabe für meine Konfiguration des radinoCC1101 SIGNALduino-Sticks (433 Mhz)

Code Auswählen Erweitern

Internals:
   Clients    :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SD_GT:SIGNALduino_un:
   DEF        /dev/serial/by-id/usb-Unknown_radino_CC1101-if00
   DMSG       W53#01616D98854
   DevState   initialized
   DeviceName /dev/serial/by-id/usb-Unknown_radino_CC1101-if00@57600
   FD         12
   FUUID      5f4ea494-f33f-0bf7-3d1b-d7547ff9f0b6689a
   IDsNoDispatch 2,72.1,82
   LASTDMSG   W53#01616D98854
   LASTDMSGID 53
   MSGCNT     1032
   NAME       sduino
   NR         40
   PARTIAL   
   RAWMSG     MS;P0=-7860;P1=489;P2=-1983;P3=-4026;D=1010121212121212121312131312121212131213131213131213131212131312121213121212121312131213;CP=1;SP=0;R=41;O;
   RSSI       -53.5
   STATE      opened
   TIME       1622631432
   TYPE       SIGNALduino
   cc1101_available 1
   sendworking 0
   unknownmessages
   version    V 3.3.1 SIGNALduino cc1101 (433 Mhz ) - compiled at Dec  3 2019 19:41:55
   versionProtocols 1.21
   versionmodul v3.4.4
   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|26|29|30|34|46|68|69|76|81|83|86|90|91|91.1|92|93|95|97|99|104)#.*
     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)#.*
     28:SD_Keeloq ^P(?:87|88)#.*
     29:SD_GT   ^P49#[A-Fa-f0-9]+
     2:CUL_TCM97001 ^s[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:
   READINGS:
     2021-06-02 12:53:46   cc1101_config   Freq: 433.920 MHz, Bandwidth: 325 KHz, rAmpl: 42 dB, sens: 4 dB, DataRate: 5603.79 Baud
     2021-06-02 12:53:46   cc1101_config_ext Modulation: ASK/OOK, Syncmod: No preamble/sync
     2021-06-02 12:53:48   cc1101_patable  C3E = 00 84 00 00 00 00 00 00 => 5_dBm
     2021-06-02 12:46:38   config          MS=1;MU=1;MC=1;Mred=0
     2021-06-02 12:55:53   ping            OK
     2021-06-02 12:53:45   state           opened
   additionalSets:
   helper:
   keepalive:
     ok         1
     retry      0
   mcIdList:
     10
     11
     12
     18
     43
     47
     52
     57
     58
     96
   msIdList:
     0
     0.1
     0.2
     0.3
     0.4
     0.5
     1
     3
     3.1
     4
     6
     7
     13
     13.2
     14
     15
     17
     20
     23
     25
     33
     33.1
     33.2
     35
     41
     49
     51
     53
     54.1
     55
     65
     68
     74.1
     87
     88
     90
     91.1
     93
   muIdList:
     8
     9
     13.1
     16
     17.1
     19
     21
     22
     24
     26
     27
     28
     29
     30
     31
     32
     34
     36
     37
     38
     39
     40
     42
     44
     44.1
     45
     46
     48
     49.1
     49.2
     50
     54
     56
     59
     60
     61
     62
     64
     66
     67
     69
     70
     71
     72
     73
     74
     76
     79
     80
     81
     83
     84
     85
     86
     89
     91
     92
     94
     95
     97
     98
     99
     104
     105
Attributes:
   hardware   radinoCC1101
   room       System
   verbose    3