Signalduino Entwicklung

[Ralf9]

Da ein Internal nicht persistent ist, sollte nach dem Flashen das Gerät wieder initialisiert sein.

Alternativ sollte das Gerät mit einem "set reset" auch wieder aktiviert werden können.

Gruß Ralf

[Pythonf]

Hey Klaus,

Hallo Sidey,

mir ging es erst einmal um das Senden im Raw Format, dadurch kann  ich ein zusätzliches Gerät nur zum Senden einsparen und das klappt jetzt. Das Empfangen der Daten ist ja pro Rollade nur eine einmalige Sache. Um den Rolladencode auf zuzeichnen benutze ich folgenden Sketch  Fernotron2411RFSniffer.ino und mit Hilfe eines Scriptes wandele ich die Daten in das Signalduino Format um. Dabei ist zwar etwas Handarbeit von Nöten, aber es klappt. Wenn ich wieder Zeit habe werde ich mir die Empfangsseite einmal genauer anschauen, bis dahin wäre es nicht schlecht wenn du die Änderungen einchecken könntes.   

Gruß
Klaus

Ich finde super, dass das Projekt Fernotron@Signalduino aufgegriffen wird. Ich hatte selbst mal die Idee dazu aber nicht die erforderlichen Kentnisse das ganze umzusetzen. Das Senden von Fernotron Codes über Signalduino fänd ich schon super und wollte fragen, ob du das Skript zum konvertieren der Daten aus der FernotronSniffer.io frei zur verfügung stellen könntest ? Die Möglichkeit, wie z.B. bei Intertechno zu senden und zu empfangen fände ich natürlich genial und ich bin sehr gespannt, wie sich das ganze entwickeln wird.

Beste Grüße
Fabian

[trebron106]

Hallo Fabian,

ich hänge das Programm zur Umwandlung des Fernotron-Codes an. Es ist ein Pythonprogramm und selbst erklärend, du musst nur Fernotron-Code kopieren und an der entsprechenden Stelle einfügen,  das Programm speichern und danach starten, als Ausgabe erhältst du den Signalduinocode.

Gruß
Klaus

[Ralf9]

Hi Trebron,

ich habe deine Änderungen nun teilweise übernommen.
Der Start einer Nachricht wird meiner meinung nach Nicht >255 sein. Deshalb habe ich es hier bei dem Datentyp mit 8 bit gelassen.

Eine Möglichkeit wäre auch die Zeichenfolge zwischen "D=" und ";;" als BCD zum Arduino zu übertragen. Damit müsste sich der benötigte Speicher halbieren. Dies wäre evtl was für die dev-r33. 

Die send_raw könnte dann ungefähr so aussehen:

Code Auswählen Erweitern


void send_raw(const uint8_t startpos,const uint16_t endpos,const int16_t *buckets, String *source=&cmdstring)
{
uint8_t index;
uint8_t bcd;
unsigned long stoptime=micros();
bool isLow;
uint16_t dur;
for (uint16_t i=startpos;i<=endpos;i++ )
{
bcd = source->charAt(i);
index = bcd >> 4;           // BCD high

isLow=buckets[index] >> 15;
isLow ? dur = abs(buckets[index]) : dur = abs(buckets[index])-24;

while (stoptime > micros()){
;
}
isLow ? digitalLow(PIN_SEND): digitalHigh(PIN_SEND);
stoptime+=dur;


index = bcd & 0x0F;       // BCD low

isLow=buckets[index] >> 15;
isLow ? dur = abs(buckets[index]) : dur = abs(buckets[index])-24;

while (stoptime > micros()){
;
}
isLow ? digitalLow(PIN_SEND): digitalHigh(PIN_SEND);
stoptime+=dur;
}

while (stoptime > micros()){
;
}

}


Gruß Ralf

[trebron106]

Hallo Ralf,

werde dein send_raw einmal in meinen Test Sketch einbauen und die Daten in BCD senden. Ich melde mich nach den Test, wird aber dieses Wochenende nichts , da ich unterwegs bin.

Gruß
Klaus

[Sidey]

Hi Ralf, mit BCD meinst Du einen Wert in 4 anstatt 8 Bit übertragen?

Das habe ich auch schob überlegt, sowohl senden als empfangen.

Derzeit sind drei Bit notwendig, wobei etwas mehr Hirnschmalz notwendig ist, das auseinander zu nehmen. Bei 16 Bit wären 15 nutzbar.

Grüße Sidey

[Ralf9]

Hi Ralf, mit BCD meinst Du einen Wert in 4 anstatt 8 Bit übertragen?

Ja, ich meine einen Wert in 4 Bit. Dies müsste recht einfach umzusetzen sein.

Derzeit sind drei Bit notwendig, wobei etwas mehr Hirnschmalz notwendig ist, das auseinander zu nehmen. Bei 16 Bit wären 15 nutzbar.

Mit 3 Bit wären P0 bis P6 möglich. Kannst Du abschätzen ob dies auch in Zukunft ausreichend ist?
Sind Protokolle denkbar die mehr als P0 bis P6 benötigen?

Das mit dem mehr Hirnschmalz wäre egal. Das auseinander nehmen würde auch mehr Befehle in der send_raw bedeuten. Kann es dadurch nicht zu timing Problemen kommen? Micros sind sehr kurz

Gruß Ralf

P.S.:
Mein über USB angebundener Nano hat mittlerweile eine uptime von 12 Tagen und
mein über das Ethernet Shield angebundener pro mini hat mittlerweile eine uptime von 23 Tagen.
Wer bietet mehr?

[Sidey]

Mit 3 Bit wären P0 bis P6 möglich. Kannst Du abschätzen ob dies auch in Zukunft ausreichend ist?
Sind Protokolle denkbar die mehr als P0 bis P6 benötigen?

Ja, die gibt es, allerdings funktionieren die nicht mit dem aktuellen setup.

Das mit dem mehr Hirnschmalz wäre egal. Das auseinander nehmen würde auch mehr Befehle in der send_raw bedeuten. Kann es dadurch nicht zu timing Problemen kommen?

Nein, solange man dem Konzept folgt, dass man den Nächsten Wert berechnet, solange man noch das Signal des aktuellen moduliert.

Für das speichern kann man den bitstore nutzen, die Klasse habe ich genau für diese Zwecke erstellt. Die müsste halt auf der Fhem Seite  portiert werden. Insgesamt ja nix wildes, es werden Bits geschoben und dadurch werte Effizienz gespeichert. Aber das ganze ist wirklich eher was für 3.3

Sidey

[waschbaerbauch]

Nachdem ich mir nun auch einen 'SIGNALduino' zugelegt habe wird mein Logfile geflutet. Ich hoffe ihr könnt mir nach und nach helfen ein wenig Licht ins Dunkel zu bringen.

Der folgende Auszug könnte von meiner Aldi Wetterstation GT-WS09s stammen.

Code Auswählen Erweitern

2016.02.06 20:01:53 4: sduino/msg READ: MC;LL=-1039;LH=899;SL=-547;SH=434;D=5C7126884080;C=444;
2016.02.06 20:01:53 4: sduino/msg READ: MU;P0=-837;P1=420;P3=971;D=010101010101010103010101010101030101010101010101030103010101010101010101010101010101010101010101010101010101010103010101030103010301030103010301;CP=1;
2016.02.06 20:01:53 4: sduino: Fingerprint for MU Protocol id 27 -> remote27 matches, trying to demodulate
2016.02.06 20:01:53 4: sduino: Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
2016.02.06 20:01:53 4: sduino: Fingerprint for MU Protocol id 31 -> pollin isotronic matches, trying to demodulate
2016.02.06 20:01:53 4: sduino: Fingerprint for MU Protocol id 8 -> TX3 Protocol matches, trying to demodulate
2016.02.06 20:01:53 4: sduino: Fingerprint for MU Protocol id 9 -> CTW 600 matches, trying to demodulate
2016.02.06 20:01:53 4: sduino: decoded matched MU Protocol id 9 dmsg P9#FF7EFF5FFFFFFF7554 length 72
2016.02.06 20:01:53 4: SD_WS09_Parse HEX=P9#FF7EFF5FFFFFFF7554 length: 18
2016.02.06 20:01:53 3: SD_WS09_Parse Bin=111111110111111011111111010111111111111111111111111111110111010101010100 syncp=1 length:72
2016.02.06 20:01:53 3: EXIT SD_WS09_Parse msg=FF7EFF5FFFFFFF7554 syncp=1 length:72
2016.02.06 20:01:53 4: SIGNALduino_unknown incomming msg: P9#FF7EFF5FFFFFFF7554
2016.02.06 20:01:53 4: SIGNALduino_unknown rawData: FF7EFF5FFFFFFF7554
2016.02.06 20:01:53 4: SIGNALduino_unknown Protocol: 9
2016.02.06 20:01:53 4: SIGNALduino_unknown converted to bits: 111111110111111011111111010111111111111111111111111111110111010101010100
2016.02.06 20:01:53 1: PERL WARNING: substr outside of string at ./FHEM/90_SIGNALduino_un.pm line 187.
2016.02.06 20:01:53 1: PERL WARNING: Use of uninitialized value $winddir in concatenation (.) or string at ./FHEM/90_SIGNALduino_un.pm line 189.
2016.02.06 20:01:53 4: SIGNALduino_unknown found ctw600 syncpos at 1 message is: 111111011111111010111111111111111111111111111110111010101010100 - sensor id:110111, bat:111, temp=1110101111, hum=11111111, wind=1111111111111111, rain=1011101010101010, winddir=

[Ralf9]

Der folgende Auszug könnte von meiner Aldi Wetterstation GT-WS09s stammen.

Ich habe eine Protokollbeschreibung vom GT-WS-09 gefunden:
http://www.ludwich.de/ludwich/Temperatur.html

Gruß Ralf

[Sidey]

Hi,

der GT-WT-02 ist doch bereits im CUL_TCM97001 Modul enthalten.


Grüße Sidey

[hoods]

Hallo Klaus aka trebron106,

nutzt Du einen Arduino nano, könntest Du das hex File und/oder deinen angepassten Sketch bereitstellen?
Ich habe mir gestern die Sourcen via git clone gezogen (branch dev-r32 als auch dev-r32-vs) aber daran wird natürlich perm. weiterentwickelt und so bekomme ich Fehlermeldungen die ich mit meinen rudimentären Kenntnissen nicht mehr aufgelöst bekomme.

Danke Sven

[waschbaerbauch]

Hi,
der GT-WT-02 ist doch bereits im CUL_TCM97001 Modul enthalten.
Grüße Sidey

Ok dann bin ich grad ein wenig verwirrt.

Auf dem produktiven System hab ich die Variante mit Auriol Patch aktiv, auf dem Eval System läuft es noch ohne Patch.

EVAL:
Hier bekomme ich zwei unterschiedliche Modeltypen angezeigt. Wenn es sich hierbei um meinen Aldi Sensor handeln sollte, dann wird er nicht mit 'autocreate' angelegt wie ich es hier im Forum auf meiner Suche gelesen hatte.

Code Auswählen Erweitern

2016.02.07 11:35:12 4: SIGNALduino/msg READ: MS;P1=576;P2=-8988;P3=-4127;P4=-2128;D=1213131314131314131314131414141414141313141314131313141413131413141413141413;CP=1;SP=2;
2016.02.07 11:35:12 4: Found matched Protocol id 0 -> weather1
2016.02.07 11:35:12 5: Starting demodulation at Position 2
2016.02.07 11:35:12 5: converted Data to (sEDA06B9A4800)
2016.02.07 11:35:12 5: SIGduino dispatch sEDA06B9A4800
2016.02.07 11:35:12 4: CUL_TCM97001 using longid: 1 model: AURIOL
2016.02.07 11:35:12 2: CUL_TCM97001 Unknown device CUL_TCM97001_237, please define it


Code Auswählen Erweitern

2016.02.07 12:04:08 4: SIGNALduino/msg READ: MS;P0=-2078;P1=569;P2=-9038;P3=-4127;D=1213131310131310131310131010101010101313131010101013101013131010131313131013;CP=1;SP=2;O;
2016.02.07 12:04:08 4: Found matched Protocol id 0 -> weather1
2016.02.07 12:04:08 5: Starting demodulation at Position 2
2016.02.07 12:04:08 5: converted Data to (sEDA07099E800)
2016.02.07 12:04:08 5: SIGduino dispatch sEDA07099E800
2016.02.07 12:04:08 4: CUL_TCM97001 using longid: 1 model: Type1
2016.02.07 12:04:08 2: CUL_TCM97001 Unknown device CUL_TCM97001_237, please define it


PROD:
Hier wurde mit dem Patch das Gerät angelegt. Allerdings sind heute Nacht auch diverse 'Aufforderungen' im Logfile es zu erstellen bis dann 'autocreate' den Job selbst übernommen hat. Geändert habe ich daran allerdings nichts.

Code Auswählen Erweitern

MS;P1=588;P2=-2068;P3=-9030;P4=-4135;D=1314141412141412141412141212121212121412141212121214121412141214141414141412;CP=1;SP=3;O;
2016.02.07 07:06:27 4: SIGduino: Matched MS Protocol id 0 -> weather1
2016.02.07 07:06:27 4: SIGduino: Decoded MS Protocol id 0 dmsg sEDA050ABF000 length 40
2016.02.07 07:06:27 4: CUL_TCM97001 using longid: 1 model: Type1
2016.02.07 07:06:27 2: CUL_TCM97001 Unknown device CUL_TCM97001_237, please define it
2016.02.07 07:06:27 2: autocreate: define Type1_237 CUL_TCM97001 CUL_TCM97001_237
2016.02.07 07:06:27 2: autocreate: define FileLog_Type1_237 FileLog ./log/Type1_237-%Y-%m.log Type1_237
2016.02.07 07:06:27 2: autocreate: define SVG_Type1_237 SVG FileLog_Type1_237:temp4hum4:CURRENT
2016.02.07 07:06:27 1: ERROR: set SVG_Type1_237 copyGplotFile: Error on reading ./www/gplot/temp4hum4.gplot from database!


Code Auswählen Erweitern

2016.02.07 09:03:07 4: SIGduino/msg READ: MS;P0=583;P1=-2071;P2=-9057;P3=-4120;D=0203030301030301030301030101010101010301030103010103010301010103030303010301;CP=0;SP=2;
2016.02.07 09:03:07 4: SIGduino: Matched MS Protocol id 0 -> weather1
2016.02.07 09:03:07 4: SIGduino: Decoded MS Protocol id 0 dmsg sEDA054A3D000 length 40
2016.02.07 09:03:07 4: CUL_TCM97001 using longid: 1 model: Type1


[Ralf9]

Auf dem produktiven System hab ich die Variante mit Auriol Patch aktiv, auf dem Eval System läuft es noch ohne Patch.

was ist der Auriol Patch?

PROD:
Hier wurde mit dem Patch das Gerät angelegt. Allerdings sind heute Nacht auch diverse 'Aufforderungen' im Logfile es zu erstellen bis dann 'autocreate' den Job selbst übernommen hat. Geändert habe ich daran allerdings nichts.

Das dürfte an
autocreateThreshold => "2:180"
liegen

Code Auswählen Erweitern

autocreateThreshold => "<count>:<timeout>"
Mittels autocreateThreshold wird beeinflusst, wie oft count(default 2) und in welchem Zeitabstand timeout (default 60 Sekunden)
die gleiche Nachricht empfangen werden muss, damit ein Gerät per autocreate angelegt wird.
Das Verhalten, kann vom Anwender mittels Attribut autocreateThreshold im device "autocreate" überschrieben werden.

Hast Du evtl Empfangsprobleme, was für ein Empfänger hast Du?
So etwas wird empfohlen:

http://www.ebay.de/itm/433Mhz-3400-RF-Superheterodyne-Transmitter-Receiver-Link-Kit-fur-Arduino-ARM-MCU-/121597434875?hash=item1c4fc59bfb:g:xIUAAOSwEeFVBpt-

http://www.ebay.de/itm/Neu-Uberlagerungs-OOK-Wireless-Receiver-Modul-Starke-Interferenz-433MHZ-116dBm-/201243355169?hash=item2edb09e821:g:ehcAAOSwEppUR2NH

Gruß Ralf

[waschbaerbauch]

Der Auriol Patch ist das hier: http://forum.fhem.de/index.php/topic,48813.0.html

Meine Empfänger sind in der Tat die Superhet aus deinen Links.
Möglicherweise liegt es auch daran das ich erstmal, ziemlich pragmatisch veranlagt, als Antenne ein Breadboard Female Kabel genommen habe?!

Zum 'autocreate':
Jetzt hat vor 20 Minuten auch das EVAL System einen Eintrag erstellt. Dieser sieht aber schon etwas anders aus.