Signalduino Version 3.3.1 / 3.3.2 / 3.3.3-dev

[Sidey]

Ich fasse Mal zusammen.
Bis RC8 hat das senden ganz gut geklappt.

Ab RC9 oder RC10 gibt es Probleme?


Ihr verwendet einen nano mit cc1101 nehme ich an.


Grüße Sidey

Gesendet von meinem Moto Z (2) mit Tapatalk

[Harst]

Wenn das Schalten auch über einen 433Mhz Schalter arbeitet kontrolliert bitte Mal, ob die Problematik auch da ist, wann man über die Weboberfläche schaltet.

Bei mit sendet der Schalter noch, während die Befehle an die (in diesem Fall) Steckdose gehen. Ein sleep hat dann geholfen.

Horst

[Harst]

Hallo Marco,

das scheint ein Bug im MS Dekoder zu sein, der ein falsches Padding macht:

MS;P1=-410;P2=807;P3=-803;P4=394;P5=-3994;D=45412123434123412123434341234123434121234123412121234341234343434123412343;CP=4;SP=5;R=30;O;m2;

Die letzten 4 Bits:

34 12 34 3

Die 3 am Ende deutet darauf hin, dass das Bit Muster 1011 sein sollte. Der Dekoder macht aber 1010 daraus.

Code Auswählen Erweitern


2019.01.05 06:36:37 4: sduinodummy: Matched MS Protocol id 91.1 -> Atlantic security
2019.01.05 06:36:37 5: sduinodummy: Starting demodulation at Position 3
2019.01.05 06:36:37 5: sduinodummy: Found wrong signalpattern, catched 35 bits, aborting demodulation
2019.01.05 06:36:37 1: DEBUG>sduinodummy: decoded message raw (0 0 1 1 0 1 0 0 1 1 1 0 1 0 1 1 0 0 1 0 1 0 0 0 1 1 0 1 1 1 1 0 1 0 1), 35 bits

2019.01.05 06:36:37 1: DEBUG>sduinodummy padded 1 bits to bit_msg array
2019.01.05 06:36:37 4: sduinodummy: Decoded MS Protocol id 91.1 dmsg u91#34EB28DEA length 36 RSSI = -59
2019.01.05 06:36:37 1: DEBUG>sduinodummy: dispatching now msg: u91#34EB28DEA
2019.01.05 06:36:37 5: sduinodummy Dispatch: u91#34EB28DEA, test gleich
2019.01.05 06:36:37 5: sduinodummy Dispatch: u91#34EB28DEA, -59 dB, dispatch
2019.01.05 06:36:37 5: sduinodummy: dispatch u91#34EB28DEA
2019.01.05 06:36:37 4: SIGNALduino_unknown incomming msg: u91#34EB28DEA
2019.01.05 06:36:37 4: SIGNALduino_unknown rawData: 34EB28DEA
2019.01.05 06:36:37 4: SIGNALduino_unknown Protocol: 91
2019.01.05 06:36:37 4: SIGNALduino_unknown converted to bits: 001101001110101100101000110111101010
2019.01.05 06:36:37 5: SIGNALduino_unknown: sduinodummy Protocol 191 found in AttrVal development


Gruß, Jochen

Ich habe da einen Vorschlag.

Aus dem letzte (halben) Bit und den Definitionen für Zero und one sollte sich in fast allen Fällen der fehlende Wert ergeben. Es fehlt jeweils der zum letzten token passende aus der Liste Zero und one.
Wenn das nicht eindeutig ist haben wir sowieso keine Chance auf einen richtigen Wert.

Horst

[jochen_f]

Hallo Horst,

ich habe einen Patch geschrieben, der genau das macht.

https://github.com/JochenFriedrich/RFFHEM/commit/55b81c1693d3f70c547eae419f4e63caa316c701

Der bastelt aus dem letzten halben Bit plus dem Clock das letzte Bit zusammen und dekoriert die MS Nachricht als MU.

Wenn Du das mit dem Atlantic'S Sensor testen willst, musst Du 91.1 aus der Whitelist rausnehmen. Die 91 reicht dann völlig aus und dekodiert beide Varianten.

Gruß, Jochen

[RappaSan]

Guten Morgen,

bei mir ist kein cc1101 dran, nur die einfachen 433er Sender/Empfänger.

[rcmcronny]

Moin,

auch bei mir hat der Signalduino kein cc1101, das war mal hier aus dem Forum ein nano mit normalen 433 MHz Sender/Empfänger (die SignalESPs haben aber ausschliesslich CC1101er).

Ronny

[Ralf9]

Hallo Sidey,

mir ist aufgefallen, daß es momentan bei der Entwicklerversion dev-r33 keine einfache Möglichkeit gibt eine stable firmware für den cc1101 zu flashen.

Wie soll der Anwender drauf kommen, daß dies momentan für den nano mit cc1101 nur damit geht?

Code Auswählen Erweitern

set sduino flash https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/master/FHEM/firmware/SIGNALduino_nanoCC1101.hex

Bei set flash bekommt er als stable nur 3.1 und 3.3.0 zur Auswahl, dafür gibt es aber keine hex-file für den cc1101.

Die stable V 3.3.1-dev für den cc1101 ist bei der Auswahl nicht dabei.

Gruß Ralf

[Sidey]

Hi Ralf,

V 3.3.1-dev ist ja keine stable Version, sondern eine Entwickler Version.

Und für den Nano mit cc1101 gibt es nichts, was als stable bislang veröffentlicht wurde.

Grüße Sidey

[Ralf9]

Die V 3.3.1-dev ist aber mehr stable als die RC10 und wahrscheinlich mindestens so stable wie die 3.3.0.
In der 3.3.1-dev wurden einige Fehler von der 3.3.0 beseitigt.
Die V 3.3.1-dev ist eine quasi stable Version, sie ist auch im master branch.

Wie ich gerade gesehen habe, gibt es momentan auch im svn keine Version für den cc1101.
Mir ist nicht klar wie momentan jemand, der die Version vom normalen Update verwendet eine firmware für den nano mit cc1101 flashen kann.
Wer mit der Entwicklerversion und updateChannelFW:stable versucht die 3.3.0 für den cc1101 zu flashen, wird daran evtl verzweifeln, da dies nicht funktionieren kann.

Gruß Ralf

[Sidey]

Die V 3.3.1-dev ist aber mehr stable als die RC10 und wahrscheinlich mindestens so stable wie die 3.3.0.

In der 3.3.1-dev wurden einige Fehler von der 3.3.0 beseitigt.
Die V 3.3.1-dev ist eine quasi stable Version, sie ist auch im master branch.

Ich weiss nicht wie Du darauf kommst, dass eine Entwicklerversion = stable Version ist.
Den Code habe ich mir jetzt nicht mehr angesehen, aber da fehlen vermutlich Dinge um die Frequenz anzupassen und die Probleme mit dem MC Decoder sind dort ganz sicher auch enthalten.

Mir ist nicht klar wie momentan jemand, der die Version vom normalen Update verwendet eine firmware für den nano mit cc1101 flashen kann.

Aktuell nur über den im Wiki hinterlegten Weg:
https://wiki.fhem.de/wiki/SIGNALduino#Vorabversion_einer_Firmware

Wer mit der Entwicklerversion und updateChannelFW:stable versucht die 3.3.0 für den cc1101 zu flashen, wird daran evtl verzweifeln, da dies nicht funktionieren kann.

Das stimmt. Es wird keine kompatible Firmware gefunden werden. Dazu könnte man eine passende Fehlermeldung generieren.

[rcmcronny]

Hi,

ich weiss nicht warum, aber seit einem Umbau und damit PowerOff / lange auslassen / Power wieder an beim FHEM Pi, scheint der SignalDuino wieder wie normal zu arbeiten, bisher konnte ich keine Aussetzer bei IT mehr nachstellen, ich werde es aber noch beobachten (find ich komisch irgendwie).

Noch was, was mich schön länger stört, aber wo ich wohl zu "doof" bin, das zu fixen:

Ich habe einen Temp Sensor (NC_xx) im Modul CUL_TCM97001, der funzt wie er soll, dummerweise kommen dann immer durchs autocreate hier welche aus der Umgebung mit rein, die angelegt werden, durch Blacklist/Whitelist kann ich diese glaube schwer beeinflussen oder ? Was gibts da noch für Möglichkeiten, diese nicht mehr anlegen zu lassen.  (das sind dann andere NC_xx Sensoren, Ario, GT, WT und so kram, hab Sie schon gelöscht und müsste nochmal genauer schauen, aber vielleicht hat jemand einen Tip für mich, als Startpunkt ?

Danke Ronny

[RappaSan]

Moin.

Schalt doch autocreate aus oder mit zusätzlichem
attr autocreate ignoreTypes NC.*

[rcmcronny]

Hi

ach stimmt, da hatte ich sogar schonmal was angefangen, danke für den großen Zaunspfahl

Ronny

[Harst]

Hallo,

vor ein paar Tagen hatte ich einen Vorschlag für das Dekodieren des letzten Bit bei MS-Nachrichten gemacht. Es gibt zwar schon den Patch von Jochen, der daraus MU-Nachrichten macht, ich habe es jetzt in den eigentlichen Dekoder eingebaut.

Methode:
Es wird ein 2. Hash angelegt, der ein um ein Zeichen verkürztes Muster von one und zero erhält.
Wenn das nicht eindeutig ist wird das Verfahren verworfen.
Wenn am Ende ein halbes Bit steht wird versucht, diesen 2. Hash zum Dekodieren des letzten Bit zu verwenden.

Perl ist jetzt nicht meine Sprache, aber der Stil ist ja vorgegeben, es sind auch nur wenige Zeilen und ergibt bisher immer die richtigen Checksummen.

Besteht Interesse, das zu integrieren / anzusehen?
Wenn ja wie?

Grüße

Horst

[Jogi]

Hallo,
in der Hoffnung, dass meine Frage hier richtig ist und nicht schon beantwortet wurde (habe mit meiner Suche nichts gefunden):
Ich habe mir einen Signalduino zugelegt, mit dem ich FS20 Steckdosen schalten wollte. Doch scheinbar geht das nicht.
Die Signale der Fernbedienung werden zwar erkannt, aber senden kann ich nichts.
Unter clients ist FS20 zwar aufgeführt:

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_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:SIGNALduino_un:
   DEF        192.168.178.121:23
   DMSG       nothing
   DevState   initialized
   DeviceName 192.168.178.121:23
   FD         42
   LASTDMSG   nothing
   NAME       Sduino868Mhz
   NR         545
   PARTIAL   
   STATE      opened
   TIME       1547897651
   TYPE       SIGNALduino
   cc1101_frequency 868
   sendworking 0
   version    V 3.3.1-rc4 SIGNALESP cc1101 868MHz - compiled at Mar 22 2018 23:44:15
   MatchList:
     10:SD_WS07 ^P7#[A-Fa-f0-9]{6}F[A-Fa-f0-9]{2}(#R[A-F0-9][A-F0-9]){0,1}$
     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   ^u30#.*
     18:FLAMINGO ^P13#[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
     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:
     2019-01-18 12:01:19   ccconf          freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB  (DataRate:5603.79Baud)
     2019-01-09 15:51:52   ccpatable       C3E = 00 84 00 00 00 00 00 00
     2019-01-09 15:52:03   cmds            V R t X F S P C r W x e
     2019-01-09 15:52:12   config          MS=1;MU=1;MC=1
     2019-01-18 12:19:59   ping            OK
     2019-01-19 12:57:52   state           opened
     2019-01-19 12:57:52   version         V 3.3.1-rc4 SIGNALESP cc1101 868MHz - compiled at Mar 22 2018 23:44:15
   keepalive:
     ok         0
     retry      0
   mcIdList:
     10
     11
     12
     18
     43
     47
     52
     57
     58
   msIdList:
     0
     1
     13
     14
     15
     17
     2
     22
     23
     25
     3
     3.1
     32
     33
     35
     38
     4
     41
     51
     55
     6
     68
     7
     72.1
   muIdList:
     13.1
     16
     20
     21
     24
     26
     27
     28
     29
     30
     31
     36
     37
     39
     40
     44
     44.1
     45
     46
     48
     49
     5
     50
     56
     59
     60
     61
     62
     64
     65
     66
     67
     69
     70
     71
     72
     75
     8
     9
Attributes:
   cc1101_frequency 868
   flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:[HEXFILE] 2>[LOGFILE]
   group      Gateways
   hardware   nanoCC1101
   icon       cul_868
   room       99.Programm,FS20
   verbose    5
aber mit get protocollIDs bekomme ich

Code Auswählen Erweitern

74 MU FS20            FS20 # Remote Control (868Mhz only receive)
Frage: Ist angedacht, dass der Signalduino auch irgendwann mal FS20-Signale senden kann, oder kann er das schon und ich mache nur etwas falsch?

Vielen Dank und Grüße,
Jogi