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

Begonnen von andies, 22 Juli 2017, 19:07:16

Vorheriges Thema - Nächstes Thema

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
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.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

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

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,

FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

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

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

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

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?
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

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.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

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.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

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.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

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.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

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

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

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

andies

Zitat von: Sidey am 23 Juli 2017, 10:09:45
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?

Zitat von: Sidey am 23 Juli 2017, 10:09:45
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:
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...
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

andies

#10
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?
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

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.. :-\
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

andies

Zitat von: KölnSolar am 23 Juli 2017, 21:01:36
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...

Zitat von: KölnSolar am 23 Juli 2017, 21:01:36
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!   

Zitat von: KölnSolar am 23 Juli 2017, 21:01:36
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.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

KölnSolar

ZitatAlso 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

ZitatIntertechno 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.

ZitatIch 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 ?

ZitatMomentan 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
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

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, ...
Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...