[mehr oder weniger gelöst] Funkprotokoll divers. "Intertechno-kompatible Geräte"

[andies]

Ich habe eine Funksteckdose von reichelt, die ich mit FHEM betreiben will. Angeblich ist sie Intertechno-kompatibel, V1. Leider stimmt das nicht, jedenfalls lässt sie sich nicht ohne weiteres ansprechen. Die Fehlermeldungen sind aber so unsystematisch, dass ich eher Probleme bei der Signalstärke oder ähnliches vermute. Aber darum soll es jetzt nicht gehen.

Ich habe mir eine Installation mit Hilfe eines 433-Senders aus China und einem Mikroprozessor gebaut, die eine dieser Funksteckdose erfolgreich anspricht. Das ganze wurde über einen arduino und rc-switch programmiert. Klingelt jemand an der Tür, schaltet (über einen galvanisch getrennten Kontakt) sich eine Funksteckdose für fünf Sekunden ein und dann wieder aus. So weit, so gut. Jetzt kommt mein Problem.

Ich möchte gern, dass nicht nur die Funksteckdose eingeschaltet wird, sondern dass auch ein Signal gesendet wird, das FHEM empfangen kann (und das dann weiter verarbeitet werden kann). Dazu müsste der Mikroprozessor dem 433-Sender eine Signalfolge mitgeben, die von FHEM als angebliches Intertechno-Signal interpretiert werden kann. rc-switch programmiert das so, dass man einfach die Abfolge der Zeiten, in der HIGH bzw LOW gesendet wird, mitteilt. Man sendet so etwas wie

Code Auswählen Erweitern

send raw 100 200 200 100 usw
und dann kommen 100 Mikrosekunden HIGH, 200 LOW, wieder 200 HIGH und 100 LOW usw.

Ich versuche nun herauszubekommen, was genau FHEM sendet bzw empfängt, wenn es die Intertechno-Steckdosen anspricht. Ich kriege das nicht heraus. Das Protokoll ist zwar bekannt, aber ich habe das Gefühl, dass mein SIGNALduino (Selbstbau mit einem CC1101) dieses Protokoll verzerrt umsetzt. Das heißt, ich sende 100-200-200 und in Wirklichkeit wird aber 100-150-150 (zum Beispiel) gesendet.

Mich würde interessieren, ob jemand sich so etwas schon einmal angeschaut hat und damit einige Erfahrung hat. Ich möchte gern meinen Mikroprozessor so programmieren, dass er fehlerfrei FHEM unterrichtet und bisher gelingt mir das nicht. Mal wird das Signal empfangen, mal nicht. Das liegt auch nicht an der Entfernung zum SIGNALduino, alles schon getestet. Alles, was ich bisher mit arduino & Co auslesen kann, entspricht nicht ganz dem Protokoll von Interntechno und das dürfte ja nicht sein. Also vermute ich, dass es solche Verzerrungen sind, über die ich hier bisher fast nichts im Forum gelesen habe.

[andies]

PS Hier mal der "Rohempfang" eines FHEM-Protokolls, das angeblich Intertechno sein soll. Empfangen mit einem arduino und einem RXB6:

Code Auswählen Erweitern

8944,344,800,276,908,232,920,800,400,192,940,828,316,276,904,240,900,280,900,240,904,280,900,832,308,244,900,280,900,240,900,832,348,244,896,836,348,244,896,836,308,284,896,836,308,284,892,248,956,

9032,264,880,300,884,256,888,840,352,240,900,828,316,276,900,244,900,280,896,248,896,244,896,876,308,240,900,284,896,244,900,832,348,244,896,836,308,284,896,836,304,288,892,840,304,284,892,252,952,

9036,264,880,296,888,252,892,836,356,236,900,828,360,232,904,240,900,280,904,236,904,280,900,832,312,280,900,240,900,240,900,872,312,240,900,832,348,244,896,836,352,240,896,836,308,280,900,244,960,

9028,304,880,260,884,252,932,836,316,236,900,832,352,240,900,280,900,240,900,244,900,280,900,832,308,284,896,244,900,280,900,836,308,240,900,872,308,244,896,836,348,248,892,836,344,248,892,248,956,

9036,300,880,260,884,296,888,836,316,276,900,832,316,236,904,276,904,240,900,280,900,240,900,832,352,240,900,240,900,284,900,832,308,284,900,832,308,280,900,832,312,240,900,872,308,244,896,284,920,

9036,264,880,260,924,256,888,832,320,272,908,824,320,272,904,240,904,236,904,280,900,240,900,832,352,240,900,280,900,240,900,836,308,280,900,832,312,280,900,832,308,284,896,836,308,244,896,284,916,

9036,304,880,260,884,296,888,836,316,276,864,868,316,236,900,280,904,240,900,280,900,240,900,832,352,240,896,248,896,284,896,836,308,284,896,836,308,244,896,872,308,244,896,836,348,244,896,284,920,



[Sidey]

Tia, das mit dem verzierten ist so:

Der Arduino hat einen Quarz. Dadurch wird der Takt bestimmt.
Die quarze unterliegen einer gewissen Ungenauigkeiten.

200 Mikrosekunden auf einem Arduino können zu einem anderen abweichen.

Dann kommt noch hinzu, wenn der Sender den Pegel ändert, kann das beim Empfänger durchaus etwas dauern, bis es festgestellt wird.

Ich kann mit Sicherheit sagen, dass der Signalduino das V1 Protokoll exakt nachbildet. Kleine Ungenauigkeiten können durch den Arduino entstehen. Der cc1101 könnte auch noch ein kleines bisschen was verursachen.

Bislang gab es damit aber noch keine Probleme.

Grüße Sidey


Gesendet von meinem XT1650 mit Tapatalk

[andies]

Könnte es sein, dass die Funksteckdose gar nicht exakt Intertechno ist? (Was ich aber nicht kapiere, ist, dass pilight damit keine Probleme hat. Das könnte aber auf den CC1101 deuten, denn bei pilight verwende ich den nicht.) Wie kann ich denn den "Fehler" beim CC1101 messen?

[KölnSolar]

Ich hab zwar keinen S'duino, gehe aber mal schwer davon aus, dass der genauso gut wie ein CUL funktioniert.  IT-V1 macht bei mir null Probleme. Mit verschiedenen Original-IT-V1 und Derivaten. Sogar ein 868er auf 433.92 eingestellt funktioniert überraschend gut. Abweichungen von den programmierten Pulslängen 420/1260 sind, wie Sidey schon schrieb, normal und die Geräte tolerieren das auch.

Ich versteh jetzt aber auch nicht, warum Du FHEM(Signalduino, CUL, IT...) an der Stelle anzweifelst  und den umgekehrten Weg(S'duino senden u. Arduino Eigenbau-Empfang) gehst

Sende doch einfach wie in Deinem Eingangspost nachgefragt mit dem Arduino:

IT-V1-Protokoll in 12 Tristates mit 0=420H1260L420H1260L  ; F=420H1260L1260H420L   Dem ganzen ein Syncbit(420H10000L) vorangestellt und das komplette Paket 6 mal wiederholt. Nachlesbar in der intertechno.c der aculfw.

[andies]

Weil ich es nicht geschafft habe, das auf meinem Sduino einzurichten. Ich war alnge am verzweifeln und bin dann den Umweg über pilight gegangen, das funktioniert. Ab und an überlege ich nun, woran es liegt. Ich bin mir sicher, dass es nicht an der Programmierung liegt und vermute die Probleme beim (chinesischen?) CC1101.

Ich hatte so was mal beim XY-MV-5. Ich habe da wochenlang programmiert und das Gerät kann einfach nicht ordentlich senden. Ich habe mir einen Wolf gesucht, bis mir ein besserer Transmitter unter die Finger kam.

[KölnSolar]

Ja, immer wieder blöd beim "ersten" mal, wenn man nicht weiß wo der Bug steckt.
Vielleicht gar kein 433er CC1101 ? https://wiki.fhem.de/wiki/Selbstbau_CUL
Du kannst doch mit pilight auch IT-V1 senden. Wenn Dein Signalduino das nicht vernünftig empfängt ist etwas im Argen.

[andies]

Ja, denke ich auch. Ich habe zwei von diesen preiswerten arduinos verschlissen (ich arbeite mit Mac), bis ich herausbekam, dass ich einen FTDI-Chip brauche. Die preiswerten sind übrigens beide über den Jordan. Ich habe daher für den Selbstbau nur Originalteile gekauft.

[Sidey]

Ich glaube wir kreisen ein wenig um das Problem herum.

Wenn Du den cc1101 ausscießen möchtest, dann kannst Du auch ein Stück Draht zwischen sduino (sendepin) und Arduino (Empfang) verwenden.

Geht natürlich auch umgekehrt.

Mit ein paar Logs vom Signalduino hätte man auch ein paar konkretere Daten.

Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

[andies]

Wenn Du den cc1101 ausscießen möchtest, dann kannst Du auch ein Stück Draht zwischen sduino (sendepin) und Arduino (Empfang) verwenden.

Das verstehe ich jetzt nicht. Du meinst "als Fehlerquelle auschließen"? Aber wieso soll ich das dann verkabeln?

Wenn DMit ein paar Logs vom Signalduino hätte man auch ein paar konkretere Daten.

Hier sind ein paar raw-messages, wenn ich die FB drücke:

Code Auswählen Erweitern

MS;P0=-315;P1=298;P2=-907;P3=932;P4=-9463;D=14121212301230121212121230123012121230123012301212;CP=1;SP=4;R=29;
MS;P2=-9473;P3=272;P4=-926;P6=902;P7=-338;D=32343434673467343434343467346734343467346734673434;CP=3;SP=2;R=13;O;
MS;P2=-933;P3=278;P4=878;P5=-341;P7=-9441;D=37323232453245323232323245324532323245324532453232;CP=3;SP=7;R=254;O;
MS;P2=-9433;P3=269;P4=-949;P5=862;P6=-347;D=32343434563456343434343456345634343456345634563434;CP=3;SP=2;R=15;O;

Die werden anscheinend erkannt. Es könnte natürlich auch sein, dass die (billige) Steckdose selbst das Problem ist, Arrrrgh...

[andies]

Ich muss das wohl genauer beschreiben, was mein Problem war. Ich habe eine Außen-Klingel, die bei Signal ein Relais schaltet. Ich habe eine Leitung von diesem Relais in mein Wohnzimmer gelegt. Dort habe ich also einen potentialfreien Kontakt ("Klingelkontakt"), wenn es klingelt. Das wollte ich irgendwie mit FHEM verbinden. Zudem sollte die Klingel im Wohnzimmer verstärkt werden, die hört man sonst sehr schwer.

Der Klingelkontakt ist zu weit weg vom FHEM-Server. Also dachte ich, irgendwas mit 433MHz wird es schon bringen. Also habe ich einen Mikroprozessor (Attiny85) und einen 433MHz Sender (die preiswerten, Ihr wisst schon) gekauft und versucht, den Attiny so zu programmieren, dass er 1) ein entsprechendes 433MHz-Signal sendet und 2) eine Funksteckdose schaltet. An die Funksteckdose kam dann eine richtig laute Klingel (220V).

Nun fingen die Probleme an. Wie programmiert man den Attiny, so dass er 1) die Funksteckdose schaltet und 2) FHEM unterrichtet. Ich habe beides nicht hinbekommen. Ich vermute inzwischen, dass der preiswerte 433MHz-Sender das Problem darstellt, weil ich mir einen Wolf gesucht habe. Irritiert hat mich nur, dass die Funksteckdose nach wie vor ihren Dienst versieht. Konkret ist das so gelöst:

*) Der Attiny hat eine Bibliothek, die heißt rc-switch(https://github.com/sui77/rc-switch/blob/master/RCSwitch.cpp). Mit der schalte ich die Dose. Klappt ohne Probleme und sehr zuverlässig. Sobald der Klingelkontakt da ist, schaltet sich die Funksteckdose für 5 Sekunden ein und dann aus.
*) FHEM reagiert auf diese Schaltung extrem unzuverlässig. Mal sieht es das Signal, öfter jedoch nicht. Klingelt es also, merkt FHEM das ganz oft nicht.

Das ist komisch, weil beides Intertechno sein soll. Dann habe ich angefangen, mir die Rohdaten anzuschauen. Und die sehen nicht so aus, wie Intertechno überall beschrieben wird. Also ist vermutlich der 433-Sender Schrott. Nur warum schaltet dann diese blöde Steckdose so zuverlässig - das hat mich verrückt gemacht. Diese Frage kann ich bis heute nicht beantworten.

Sobald ich meinen arduino wieder habe, werde ich das neu programmieren. Einmal werde ich ein rc-switch-Signal auslösen, das die Steckdose schaltet. Und dann noch händisch ein anderes Signal auslösen, welches FHEM bemerkt. Das Signal wird vermutlich nur durch trial-error bestimmt, denn wenn der Sender Schrott ist, wird er ja gerade nicht das senden, was ich ihm sage, sondern etwas anderes. Mal sehen, ob und wie das geht.

Habe ich mich verständlich machen können?

[KölnSolar]

Zumindest hab ich etwas mehr verstanden 

Ich hab auch mit attiny85+rc-switch(glaub ich)+billig-sendemodul einen Sender gebastelt. Wurde perfekt von FHEM erkannt. Ist aber alles länger her u. ich müsste tiiiiieeef kramen f. Details.

Deinen allerersten Satz im 1. Post hab ich immer noch nicht verstanden. Gibt es keine FB zu der Dose ? Wie bist Du auf den nicht-IT-V1-Code gekommen und was ist daran anders als IT-V1 ?

Und den S'duino hast Du neu und kein anderes 433-sendedevice zum testen ? Du hattest doch auch pilight erwähnt. Dann hast Du doch einen Sender..

[andies]

Ich hab auch mit attiny85+rc-switch(glaub ich)+billig-sendemodul einen Sender gebastelt. Wurde perfekt von FHEM erkannt. Ist aber alles länger her u. ich müsste tiiiiieeef kramen f. Details.

Also wenn Du mal Zeit haben solltest...

Deinen allerersten Satz im 1. Post hab ich immer noch nicht verstanden. Gibt es keine FB zu der Dose ? Wie bist Du auf den nicht-IT-V1-Code gekommen und was ist daran anders als IT-V1 ?

Doch, es gibt eine FB. Die habe ich mit einem RXB6 und arduino (und rcswitch-raw) "ausgelesen" und dabei kamen eben keine Intertechno-Zeitfolgen heraus. Intertechno hat eine ITClock von 250, da war es 300 bis 350. "0" und "F" sind bei Intertechno Folgen der Form 1*ITClock LOW, 3*ITClock HIGH usw, bei mir war es eher 1*ITClock und 2*ITClock. Rätselhaft. Wie gesagt: Ich rede von der Fernbedienung!   

Und den S'duino hast Du neu und kein anderes 433-sendedevice zum testen ? Du hattest doch auch pilight erwähnt. Dann hast Du doch einen Sender..

Ich habe nur zwei Sender: Einmal CC1101, der ist in FHEM fest verbaut. Und dann einen billigen aus China, den ich bei diesem Teil im Wohnzimmer verlötet habe. Ich hatte noch einen dritten, aber der war ganz schlimm - da ging weder Steckdose noch FHEM, den habe ich gleich entsorgt. Selbst der (China-)arduino hat sich verabschiedet. Momentan kann ich also nicht wirklich viel probieren, Bestellungen sind auf dem Weg.

[KölnSolar]

Also wenn Du mal Zeit haben solltest...

eher vorerst nicht, aber  guck mal hier Das ist der Thread mit meinen Anfängen zu mc's . Vielleicht findest Du da was

Intertechno hat eine ITClock von 250

hmmm, ob das stimmt ? Ich hab da 350 im Kopf und mein Post mit den Werten aus der aculfw sagt(auch für mich überraschend) 420 
und wie gesagt, die Toleranzen sind groß.

Hast Du denn jemals die FB mit dem S'duino ausgelesen ? Da kann man doch die itclock-einstellung ermitteln. Hat Ralf kürzlich erst gepostet.

Ich habe nur zwei Sender: Einmal CC1101, der ist in FHEM fest verbaut. ....

Wer soll das nun wieder verstehen ? Meinst Du den CC1101 im S'duino, der am Server angesteckt ist, auf dem FHEM läuft ?

Momentan kann ich also nicht wirklich viel probieren, Bestellungen sind auf dem Weg.

Dann leg Dir doch ne Betty über die Bucht zu. Mein Zeitproblem 

edit: die betty funkt mit 360

[RaspiLED]

Hi,
Die billigen Sender senden nix inhaltlich falsches, die haben nur eine bescheidene Reichweite. Dein FHEM hört also knapp nix oder eben doch, während die IT Dose daneben alle versteht.
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

[andies]

hmmm, ob das stimmt ? Ich hab da 350

Sorry, 350. Ich hatte das verwechselt. Bei mir hatte ich abweichend (ich glaube) dann 250 gemessen...

Hast Du denn jemals die FB mit dem S'duino ausgelesen ? Da kann man doch die itclock-einstellung ermitteln. Hat Ralf kürzlich erst gepostet.

Ja, habe ich. Die Werte sind im Post #9.

Meinst Du den CC1101 im S'duino, der am Server angesteckt ist, auf dem FHEM läuft ?

Ja, genau. Der Server ist hinter einer Holzwand versteckt, und die muss ich jedes Mal abnehmen, wenn ich da ran will. Deshalb habe ich "verbaut" gesagt.

[andies]

Die billigen Sender senden nix inhaltlich falsches, die haben nur eine bescheidene Reichweite.

Das kann ich nicht beurteilen, das hoffe ich aber auch. Die billigen Empfänger dagegen machen durchaus Probleme, das habe ich mal früher durchgemessen: https://www.raspberrypi.org/forums/viewtopic.php?p=1089248#p1089248

[KölnSolar]

das stimmt. Das ist allgemeiner Tenor. Der Sender des China-Doppelpack ist durchaus OK. Der Empfänger für die Tonne....Aber selbst der geht auf 2m 

Die Werte sind im Post #9.

Ahhh, aber ich bin ja S'duino-Dummie. Ich vermute aber, dass das die P-Werte(wie Puls ?) sind. Die sehen doch gar nicht so daneben aus. Und im Log taucht da nix anderes auf ? Keine IT-Meldungen bei verbose 5 ? Für autocreate musst Du 2-mal hintereinander on dücken.

[andies]

Ja, die sehen ziemlich genau so aus, wie sie aussehen sollen: 300-350 Pulselänge, Signal 1P-3P, Sync 31P.


Gesendet von iPhone mit Tapatalk Pro

[Sidey]

Hmm, also in Post#9 hattest Du mit der Fernbedienung gesendet und das wurde vom Signalduino empfangen.

Also ist Fernbedienung und Signalduino doch erst Mal okay.

Jetzt hast Du etwas von einem attiny und rcswitch geschrieben.

Wieso ein attiny. Mit welcher Taktfrequenz lässt du den attiny laufen. Ich selbst habe auch schon mal einen Sensor mit einem Attiny gebaut. Wenn der auf 1 MHz läuft, dann klappt das mit delaymicros nicht so ganz.

Da ist dann eine andere Variante die bessere.

Zu dem was der attiny sendet habe ich jetzt keine Logaten des sduino gefunden. Kannst Du die noch Mal Posten?

So am Rande: Ich sende immer mit dem billig China Sender. Das geht gut. Habe aber auch noch eine Helix Antenne dran.


Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

[andies]

Wieso ein attiny. Mit welcher Taktfrequenz lässt du den attiny laufen. Ich selbst habe auch schon mal einen Sensor mit einem Attiny gebaut. Wenn der auf 1 MHz läuft, dann klappt das mit delaymicros nicht so ganz.

Aha, wieder was gelernt. Natürlich habe ich 1MHz Also ist 8MHz besser?

Da ist dann eine andere Variante die bessere.

Welche genau?

Zu dem was der attiny sendet habe ich jetzt keine Logaten des sduino gefunden. Kannst Du die noch Mal Posten?

Ja, habe ich auch gemacht. Die sind hier:

Code Auswählen Erweitern


13:50:02  MS;P0=513;P1=-11365;P3=-1446;P4=1205;P5=-632;D=010303450345030303030345034503450303034503030345;CP=0;SP=1;R=40;O; #also das sieht durchaus aehnlich aus, aber pulselength = 513?!

13:50:02  MU;P0=-20464;P1=-6172;P2=168;P3=-168;P4=474;P5=-1420;P6=1194;P7=-757;D=454545674567454545454567456745674545450041474523;CP=4;R=56; # ich bin mir sicher, dass das vom attiny kommt. Eine pulselength ist verrueckt, 168, sonst 474?!

13:50:03  MS;P0=-11358;P1=534;P2=-1301;P3=1249;P4=-602;D=10121212341234121212121234123412341212123412121234;CP=1;SP=0;R=61; # auch hier sicher vom attiny, ich habe ganz oft ausgeloest

13:50:06  MS;P0=-1430;P1=530;P2=1234;P3=-616;P5=-11323;D=15101010231023101010101023102310231010102310231010;CP=1;SP=5;R=63;O; # dto

13:50:07  MS;P0=-596;P1=553;P2=-1295;P3=1239;P4=-11305;D=14121212301230121212121230123012301212123012301212;CP=1;SP=4;R=64;

13:50:12 MS;P0=-1382;P1=1217;P2=-658;P3=559;P4=-11323;D=34303030123012303030303012301230123030301230303012;CP=3;SP=4;R=55;O;

13:50:13 MS;P0=-1339;P1=559;P2=1246;P3=-656;P4=-11292;D=14101010231023101010101023102310231010102310101023;CP=1;SP=4;R=62;O;

13:50:13 MS;P0=-1315;P1=1236;P2=-604;P3=532;P4=-11366;D=34303030123012303030303012301230123030301230303012;CP=3;SP=4;R=61;

13:50:16  MS;P1=523;P2=-1394;P3=1207;P4=-640;P5=-11367;D=15121212341234121212121234123412341212123412341212;CP=1;SP=5;R=59;O;

13:50:17  MS;P0=-1426;P1=592;P2=1256;P3=-592;P4=-11301;D=14101010231023101010101023102310231010102310231010;CP=1;SP=4;R=60;O;

MS;P0=-623;P1=514;P2=-1317;P3=1224;P4=-11309;D=14121212301230121212121230123012301212123012301212;CP=1;SP=4;R=61;

13:50:33  MU;P0=-7824;P1=481;P2=-1369;P3=1181;P4=-717;P6=900;P7=-1052;D=01212123412341212121212341234123412121234121212671;CP=1;R=53;


Der eventmonitor hatte

Code Auswählen Erweitern

2017-07-23 13:49:49 SIGNALduino sduino DMSG u63AAABD6EED6AB6DFABB5ADDF6D55E8
2017-07-23 13:49:49 SIGNALduino sduino UNKNOWNCODE u63AAABD6EED6AB6DFABB5ADDF6D55E8

2017-07-23 13:50:02 SIGNALduino sduino DMSG u6356D55B6A0
2017-07-23 13:50:02 SIGNALduino sduino UNKNOWNCODE u6356D55B6A0

2017-07-23 13:50:17 SIGNALduino sduino DMSG u41#141514
2017-07-23 13:50:17 SIGNALduino sduino UNKNOWNCODE u41#141514

2017-07-23 13:50:33 SIGNALduino sduino DMSG u6356D55B6AD58
2017-07-23 13:50:33 SIGNALduino sduino UNKNOWNCODE u6356D55B6AD58

2017-07-23 13:50:49 SIGNALduino sduino DMSG u63AAF5BBB5AADB7EAED6B77DB557A
2017-07-23 13:50:49 SIGNALduino sduino UNKNOWNCODE u63AAF5BBB5AADB7EAED6B77DB557A

aber mir schien, dass er nicht jedes ausloesen erfasst hatte.

Der Logfile enthält dann noch weitere Daten, weil natürlich versucht wird, diese Daten zu dekodieren. Das gelingt dann nicht:

Code Auswählen Erweitern

2017.07.23 13:49:49 5: sduino: applying filterfunc SIGNALduino_filterSign
2017.07.23 13:49:49 5: sduino: applying filterfunc SIGNALduino_compPattern
2017.07.23 13:49:49 4: sduino: Fingerprint for MU Protocol id 44 -> BresserTemeo matches, trying to demodulate
2017.07.23 13:49:49 5: sduino: start pattern for MU Protocol id 44 -> BresserTemeo mismatches, aborting
2017.07.23 13:49:49 4: sduino: Fingerprint for MU Protocol id 44.1 -> BresserTemeo matches, trying to demodulate
2017.07.23 13:49:49 5: sduino: Starting demodulation at Position 7
2017.07.23 13:49:49 5: sduino: dispatching bits: 0 0 0 0 0 1 1 1 0 0 1 0 1 1 0 1 1 0 1 0 0 1 0 0 0 0 1 0 1 0 1 0 1 1 1 1 1 0 0 0 1 1 0 1 0 0 1 0 0 1 0 1 1 0 1 1 1 1 0 1 0 1 0 0 0 0 0 1 1 1 0 0
2017.07.23 13:49:49 4: sduino: decoded matched MU Protocol id 44.1 dmsg W44x#072DA42AF8D25BD41C length 72 RSSI = -60
2017.07.23 13:49:49 5: sduino Dispatch: W44x#072DA42AF8D25BD41C, test ungleich: disabled
2017.07.23 13:49:49 5: sduino Dispatch: W44x#072DA42AF8D25BD41C, -60 dB, dispatch
2017.07.23 13:49:49 5: sduino: dispatch W44x#072DA42AF8D25BD41C
2017.07.23 13:49:49 4: SD_WS_Parse: Protocol: 44x, rawData: 072DA42AF8D25BD41C
2017.07.23 13:49:49 4: SD_WS_Parse BresserTemeo: Humidity > 79  Flag
2017.07.23 13:49:49 4: SD_WS_Parse BresserTemeo: new bin 1000001110010110110100100001010101111100011010010010110111101010000011100
2017.07.23 13:49:49 4: sduino SD_WS_Parse: model=BresserTemeo, temp=21.5, hum=83, channel=1, id=6D, bat=ok
2017.07.23 13:49:49 5: sduino: applying filterfunc SIGNALduino_filterMC
2017.07.23 13:49:49 4: sduino: Fingerprint for MU Protocol id 63 -> Warema matches, trying to demodulate
2017.07.23 13:49:49 5: sduino: Starting demodulation at Position 0
2017.07.23 13:49:49 5: sduino: dispatching bits: 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 1 1 1 0 1 0 1 1 0 1 1 1 0 1 1 1 0 1 1 0 1 0 1 1 0 1 0 1 0 1 0 1 1 0 1 1 0 1 1 0 1 1 1 1 1 1 0 1 0 1 0 1 1 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 1 1 0 1 1 1 1 1 0 1 1 0 1 1 0 1 0 1 0 1 0 1 0 1 1 1 1 0 1 0 0 0
2017.07.23 13:49:49 4: sduino: decoded matched MU Protocol id 63 dmsg u63AAABD6EED6AB6DFABB5ADDF6D55E8 length 116 RSSI = -60
2017.07.23 13:49:49 5: sduino Dispatch: u63AAABD6EED6AB6DFABB5ADDF6D55E8, test ungleich: disabled
2017.07.23 13:49:49 5: sduino Dispatch: u63AAABD6EED6AB6DFABB5ADDF6D55E8, -60 dB, dispatch
2017.07.23 13:49:49 5: sduino: dispatch u63AAABD6EED6AB6DFABB5ADDF6D55E8
2017.07.23 13:49:49 3: sduino: Unknown code u63AAABD6EED6AB6DFABB5ADDF6D55E8, help me!
usw. usf.


[Sidey]

Hallo Andies,

Dieser Link verrät dir etwas mehr über die andere Variante:
http://forum.arduino.cc/index.php?topic=192069.0

RC Switch kannst Du weglassen, das ist nicht nötig.
Das IST Signal kann man mit ein paar Zeilen Code einfach generieren.

Ein paar Anregungen dazu kannst Du dir auch im Signalduino Quellcode bis Version 3.2 holen.
Das was dein attiny bislang gesendet hat, entspricht nicht dem IST Protokoll.

Grüße Sidey

Gesendet von meinem XT1650 mit Tapatalk

[andies]

Ich habe das jetzt wie folgt gelöst. Der nachfolgende Code funktioniert sicher, warum aber die Funksteckdose nur mir rc-switch, FHEM dagegen nur mit direkter Ansprache klappt, kann ich bis heute nicht sagen. Es kann an der Funksteckdose liegen, es kann am Sender liegen, keine Ahnung.

Code Auswählen Erweitern

//
/* Derzeit implementiert. Tastendruck löst 433MHz-Signal auf Kanal D aus, das wiederum
   eine einfache Klingel einschaltet und FHEM informiert.

   Kodierung rc-switch https://github.com/sui77/rc-switch/wiki/HowTo_OperateLowCostOutlets
   Include rcswitch, https://arduinodiy.wordpress.com/2015/04/01/using-attiny-with-rcswitch/

*************************************************/
#include <RCSwitch.h>
RCSwitch myKlingel = RCSwitch();

/*************************************************
  FHEM kann nicht mit rcswitch informiert werden, nur direkt
*************************************************/
void informFHEM()
{
  int lengthpulsetrain = 12;
  long pulses[] = {0, 1, 1, 0, 1, 1, 1, 1, 0, 1, 1, 0}; // entspricht 0FF0F (Hauscode) FFF0F (Gerätecode Steckdose D) F0 (aus)
  int repetitions = 4; //4 Wiederholungen
  for (int i = 0; i < repetitions; i++ ) {
    digitalWrite(2, HIGH); //SyncBit, auf B2
    delayMicroseconds(350);
    digitalWrite(2, LOW);
    delayMicroseconds(10850);
    for (int thisPulse = 0; thisPulse < lengthpulsetrain; thisPulse ++) {   //jetzt kommt das Signal
      digitalWrite(2, HIGH); //das ist bei 0 und F identisch
      delayMicroseconds(350);
      digitalWrite(2, LOW);
      delayMicroseconds(1050);
      if (pulses[thisPulse] == 0) //und das variiert je nach 0- oder F-Signal
      {
        digitalWrite(2, HIGH);
        delayMicroseconds(350);
        digitalWrite(2, LOW);
        delayMicroseconds(1050);
      } else
      {
        digitalWrite(2, HIGH);
        delayMicroseconds(1050);
        digitalWrite(2, LOW);
        delayMicroseconds(350);
      }
    }
  }
}
/*************************************************
  Main routine
*************************************************/
void setup()
{
  pinMode(1, INPUT); // enable Taster INPUT
  myKlingel.enableTransmit(2); // Transmitter is connected to Attiny Pin PB2
  // Optional set pulse length.
  // myKlingel.setPulseLength(270);
  // Optional set protocol (default is 1, will work for most outlets)
  // myKlingel.setProtocol(2);
  // Optional set number of transmission repetitions.
  myKlingel.setRepeatTransmit(15);
  //
  // **** Einschaltsignal *****
  myKlingel.sendTriState("0FF0FFFF0F0F"); //Klingel ein (Steckdose D)
  delay(400);
  myKlingel.sendTriState("0FF0FFFF0FF0"); //Klingel aus
  delay(400);
}


void loop()
{
  if (digitalRead(1 ) == HIGH) {
    myKlingel.sendTriState("0FF0FFFF0F0F"); //Klingel ein
    delay(3200);                            // warten
    myKlingel.sendTriState("0FF0FFFF0FF0"); //Klingel aus
    informFHEM();                           //FHEM benachrichtigen
  } else {
    delay(300);                             //300ms Kontakt muss vorliegen
  }
}