Signalduino Version 3.3.1 / 3.3.2 / 3.3.3-dev

Begonnen von Sidey, 02 Oktober 2016, 23:39:11

Vorheriges Thema - Nächstes Thema

gadget

#960
Hallo,

Ich hoffe, ich bin an dieser Stelle richtig mit meinem Anliegen. Ich habe im Schlafzimmer einen Deckenventilator ("Westinghouse"), den ich von fhem aus steuern will. Idealerweise möchte ich auch die Signale der Fernbedienung mitbekommen, da ich letztendlich ein "Auto-Off" implementieren will: Wenn der Ventilator mit der FB eingeschaltet wurde soll er durch fhem gesteuert dann nach einer Stunde wieder abschalten, also quasi ein Schlummertimer.

Mit pilight wurden für diesen Ventilator schon diverse Erfolge erzielt, ich will  aber eigentlich keinen zusätzlichen RasPi nur für diesen Zweck anschaffen. pilight ist recht CPU-intensiv ... Eine Lösung via signalduino fände ich sehr viel hübscher. Bisherige Ansätze sind aber im Sande verlaufen:
https://forum.fhem.de/index.php/topic,53282.0.html

Ich habe auf dem Breadboard auch einen V 3.3.1-dev SIGNALduino cc1101 zusammengebastelt, der auch munter irgendwelche Wetterstationen in der Nachbarschaft empfängt. Zuvor hatte ich es mit einem RXB8 probiert, der hat aber von der FB rein gar nichts empfangen.

Die FB hat 5 Tasten light,low,med,hi,off (light ist ein Toogle für die Lampe im Ventilator, low,med,hi,off steuert die Drehzahl). Im Batteriefach ist ein 4fach DIP-Schalter, der bei mir auf off-off-off-on steht. Dito natürlich auch im Empfänger im Ventilator.

Verwendet wird wohl dieser Chip: http://www.holtek.com/documents/10179/116711/2_12ev120.pdf

Im Verbose Modus empfange ich bei gedrückter Taste zigfach wiederholt folgendes:



low: sduino/msg READ: MC;LL=-492;LH=489;SL=-242;SH=247;D=D55556;C=244;L=23;R=108;
med: sduino/msg READ: MC;LL=-518;LH=493;SL=-239;SH=219;D=56AAAC;C=244;L=22;R=111;
high: sduino/msg READ: MC;LL=-495;LH=476;SL=-262;SH=239;D=55AAAC;C=245;L=22;R=110;
off: sduino/msg READ: MC;LL=-495;LH=486;SL=-251;SH=235;D=556AAC;C=244;L=22;R=109;
light: sduino/msg READ: MC;LL=-499;LH=469;SL=-260;SH=231;D=6AAAAC;C=243;L=22;R=110;



Ich habe es aber bislang nicht geschafft, per set <sduino> raw SR irgend etwas geschaltet zu bekommen, also z.B.

set sduino raw SR;;LL=-492;;LH=489;;SL=-242;;SH=247;;D=D55556;;C=244;;L=23;;R=108;;

müsste ja dann den Quirl einschalten. Passiert aber nix .... Muss ich evtl. an den Parametern des cc1101 noch was drehen oder habe ich sonst noch irgendwo einen Denkfehler ?

ccconf: freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB (DataRate:5603.79Baud)

Eine direkte Unterstützung für den Holtek-Chip wäre natürlich insgesamt super. Der wird offenbar auch in anderen Geräten eingesetzt (Rauchmelder usw.). Ich sponsore auch gerne Hardware für die Entwickler falls sich da jemand bereit findet.

In diesem Post hat sich schon mal jemand ziemlich intensiv mit dem Protokoll auseinander gesetzt:
https://forum.fhem.de/index.php/topic,53282.msg475727.html#msg475727

Grüße, gadget.

Edit: Nachdem ich im git was gelesen hatte, das es in der dev-Release wohl mit der Manchester-Dekodierung noch Fehlerkennungen gibt, habe ich diese Versuchsweise mit

set sduino disableMessagetype manchesterMC

abgeschaltet.

Und siehe da: Signalduino erkennt nun beim Betätigen der Tasten der FB auch ein Protokoll:

sduino: Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate
sduino: decoded matched MU Protocol id 29 dmsg u29#FBE length 12 RSSI = -19
SIGNALduino sduino DMSG u29#FBE

und so wie ich das verstehe, ist HT12e auch genau der Holtek-Chip, der in der FB verbaut ist. Super !

Ich bekomme für meine Tasten nun:

off: u29#FFE
low: u29#7FE
high: u29#F7E
light: u29#BFE
med: u29#FFE

Leider klappt das Senden aber immer noch nicht ..... was genau müsste ich nun verwenden, um diese Codes wieder auszusenden ?

Im Wiki steht als Beispiel: set sduino sendMsg P3#00111010#R4

Wäre das dann sinngemäß

set sduino sendMsg  P29#F7E#R4

für high ? Da passiert aber nix :-((( Warum "P" beim senden und "u" beim Empfang ? Oder ist für das HT12e Protokoll nur das Empfangen implementiert ?

Bringt es was, die RAWMSG zu senden ? Das wäre bei high:

SIGNALduino sduino RAWMSG MU;P0=-15040;P1=92;P2=-27272;P3=239;P4=-495;P5=-253;P6=474;P7=-8592;D=01234343434356434343434343567343434343564343434343435673434343435643434343434356734343434356434343434343567343434343564343434343435673434343435643434343434356734343434356434343434343567343434343564343434343435673434343435643434343434356734343434356434343;CP=3;R=107;O;

aber ich bin mir hier bezüglich der Syntax für das set sduino raw auch nicht wirklich im Klaren. Im Wiki werden die Semikolons verdoppelt und Teile der RAWMSG beim senden weggelassen ohne näher darauf einzugehen wie das gedacht ist.

Grüße, gadget.

Sidey

Zitat von: Kuzl am 13 April 2018, 12:36:09
Wann kommt denn mal eine aktuellere Version der Signalduino-firmware über das offizielle Update?
Im Moment wird Version 3.3.0 von September 2016 verteilt.

Wenn ich der Meinung bin, dass ich euch mit der 3.3.1 nicht mehr Probleme bereit als damit gelöst werden..
Über das normale Update werde ich die Binary aber nicht mehr verteilen. Da muss ich mir dann noch etwas überlegen, wie ich im FHEM einen Hinweis bringe, dass es ein neues Release gibt.
Den RC4 kannst Du bereits testen, wenn Du möchtest: https://github.com/RFD-FHEM/SIGNALDuino/releases

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Sidey

#962
Hallo Gadget,


Probier doch bitte Mal mit
set sduino sendMsg  U29#F7E#R4

Etwas zu senden.

Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Ralf9

#963
Zitatset sduino sendMsg  P29#F7E#R4

Die Daten müssen als bin gesendet werden
set sduino sendMsg  P29#111101111110#R4

Damit die Daten auch als hex angegeben werden können und die Reihenfolge der Optionen flexibler ist, muß die sendMsg Routine noch angepasst werden

In etwa so. Dies kann wahrscheinlich noch optimiert und eleganter programmiert werden:

my $arg = "U29#Ha1b2c3#R4#C300#F12#L123";
my $protocol;
my $data;
my $repeats = "";
my $clock;
my $frequency;
my $datalength;
my %sendopt;
my $n=0;
my $c;

foreach my $s (split "#", $arg) {
    $c = substr($s,0,1);
    if ($n == 0 ) {  #  protocol
        $protocol = substr($s,1);
    } elsif ($n == 1) { # Data
        $data = $s;
    } else {
        $sendopt{$c} = substr($s,1);
    }
       $n++;
}

print "id=$protocol data=$data\n";

if (defined($sendopt{'R'})) {
    $repeats = $sendopt{'R'};
    print "R=$repeats\n";
}
if (defined($sendopt{'C'})) {
    $clock = $sendopt{'C'};
    print "C=$clock\n";
}
if (defined($sendopt{'F'})) {
    $frequency = $sendopt{'F'};
    print "F=$frequency\n";
}
if (defined($sendopt{'L'})) {
    $datalength = $sendopt{'L'};
    print "L=$datalength\n";
}

if (substr($data,0,1) == "H") {   # hexdata -> nach bin wandeln, $datalength berücksichtigen wenn definiert
    print "hexdata\n";
}


Ich habe es damit getestet
https://www.tutorialspoint.com/execute_perl_online.php

@Sidey
Es wäre schön, wenn Du dies in die sendMsg Routine einbauen könntest.

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

Sidey

Huch, ich dachte, ich hätte das hätten wir schon implementiert.

Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Ralf9

Zitat von: waage am 13 April 2018, 12:47:12
Hallo Ralf
Ich hänge hier mal die bei mir funktionierende Datei an.
Waage

Ja, dies ist die aktuelle Version.

Hast Du zufällig die Version noch, die nicht funktioniert hat?

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

waage

Hallo Ralf
Hier die Datei welche nicht funktioniert hat.
Waage

Ralf9

Zitat von: waage am 14 April 2018, 19:57:25
Hallo Ralf
Hier die Datei welche nicht funktioniert hat.
Waage
Diese Datei ist auch ok, diese Datei kann eigentlich nicht die Ursache für  diese Fehlermeldung sein:
2018.04.12 16:11:39 2: autocreate: define Dooya_33C1 Dooya 33C1
2018.04.12 16:11:39 1: define Dooya_33C1 Dooya 33C1: Define Dooya_33C1: wrong address format: specify a 28 binaer id value
2018.04.12 16:11:39 1: ERROR: Define Dooya_33C1: wrong address format: specify a 28 binaer id value


Ich habe nun keine Idee/Erklärung mehr was diesen Fehler verursacht haben könnte.

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

waage

Hallo Ralf
Bei mir ist der Dateiinhalt beider Dateien unterschiedlich, in Zeile 418 und ab 1147.
Ob das Auswirkungen hat kann ich nicht Beurteilen da habe ich keine Ahnung davon.
Es ist immer Ärgerlich wenn man die Ursache für einen Fehler nicht kennt, aber das
soll vorkommen. Das eigentliche Problem fing bei mir damit an das die Rollladen nicht
in der gewählten Position stehen geblieben sind, sondern immer komplett zu bzw. auf
gefahren sind. Da dachte ich natürlich es hat sich irgendwo was geändert und habe
SIGNALduino geupdatet. Nach dem Neustart waren alle Einstellungen in der fhem.cfg
der Rollladen weg. Ich habe danach wieder eine ältere  Firmware aufgespielt alles ohne Erfolg.
Den Rest kennst Du ja.
Besten Dank nochmal für Deine Hilfe!
Gruß Waage

Kuzl

Zitat von: Sidey am 13 April 2018, 20:21:19
Wenn ich der Meinung bin, dass ich euch mit der 3.3.1 nicht mehr Probleme bereit als damit gelöst werden..
Über das normale Update werde ich die Binary aber nicht mehr verteilen. Da muss ich mir dann noch etwas überlegen, wie ich im FHEM einen Hinweis bringe, dass es ein neues Release gibt.

Aus welchem Grund willst du das nicht über das normale Update verteilen?
Gerade das war doch eigentlich das bequeme... nach dem FHEM update einfach nur auf flash drücken und fertig.
Als standard-FHEM-user will ich mir nicht aus x verschiedenen quellen meine Dateien zusammensuchen müssen.

Sidey

Zitat von: Kuzl am 17 April 2018, 13:20:53
Aus welchem Grund willst du das nicht über das normale Update verteilen?
Gerade das war doch eigentlich das bequeme... nach dem FHEM update einfach nur auf flash drücken und fertig.
Als standard-FHEM-user will ich mir nicht aus x verschiedenen quellen meine Dateien zusammensuchen müssen.

Da die Firmware compilierte ist, aber der Quellcode nicht mitgeliefert wird, ist das nicht erwünscht.

Es soll aber so einfach gehen wie zuvor.
Bereits jetzt, kannst Du hinter dem Flash Befehl eine URL angeben.
Wenn das Hardware Attribute richtig gesetzt ist, dann ist meine Idee, dass ich automatisch Abfrage, was die aktuellste Version ist.


Gruß Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

regenbieger

#971
Hi,
seit Anfang 2018 muss ich in der 00_SIGNALduino.pm Zeile 523 von 32 auf     length_min      => '31', ändern damit meine alten Oregon Temperaturdinger Daten rausrücken.
Ist das so gewollt? oder mach ich einen Fehler?
Es geht um das OSV1 Protokoll


P.S.
Danke für die super Arbeit in der Dev3.3.1 an alle Beteiligten
PPS
ist natürlich mittlerweile die v3.3.3-dev_17.04.
FHEM und WEEWX auf Raspberry

Sidey

Zitat von: regenbieger am 18 April 2018, 19:11:18
Hi,
seit Anfang 2018 muss ich in der 00_SIGNALduino.pm Zeile 523 von 32 auf     length_min      => '31', ändern damit meine alten Oregon Temperaturdinger Daten rausrücken.
Ist das so gewollt? oder mach ich einen Fehler?

Ja und nein. Das Protokoll muss 32 Bit vorweisen.
Bei 31 Bit gab es Probleme mit falschen Werten.
Wir haben an der Firmware viel verändert, so dass eine aktuelle immer 32 Bit erkennen sollte.
Welche Firmware Version setzt Du ein?

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

regenbieger

ich setze zur Zeit die version: V 3.3.1-RC4 SIGNALduino cc1101 - compiled at Mar 10 2018 23:20:23
ein.

Wenn ich mit length_min      => '31' die alten Teile nutzen kann, aber andere Trouble damit haben stelle ich es eben von Hand um.

Vielen Dank für die Info und nu aber ab in die Sonne

schönen Gruß regenbieger
FHEM und WEEWX auf Raspberry

Ralf9

#974
Interessant wären die raw-Nachrichten. Die findest Du z.B. bei den Internals (sduino_RAWMSG) vom THR128

Ich habe auch einen THR128, bei mir ist die Länge immer 32:
MC;LL=-2668;LH=3170;SL=-1214;SH=1705;D=9F56BF46;C=1459;L=32;

Ich verwende diese Firmware:
https://forum.fhem.de/index.php/topic,82379.msg744554.html#msg744554

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