Erneut: SIGNALduino und Brennenstuhl (Intertechno), Probleme bei Senden/Empfang

[andies]

Guten Abend. Ich nutze Brennenstuhl Funksteckdosen (auch Intertechno), wie man sie bei Conrad und amazon zuhauf bekommt. Mir ist aufgefallen, dass ich nicht der Einzige bin, der manchmal mit diesen Dosen Probleme hat. Im Forum finden sich einige Threads dazu. Als nun auch bei mir eine Funksteckdose trotz eindeutiger Kodierung ab und an nicht schaltete, habe ich mir mal die gesendeten Rohdaten angeschaut.

Dazu habe ich einen arduino mit einem RXB6-Empfänger verbunden, siehe https://github.com/sui77/rc-switch/wiki/HowTo_Receive. Ich habe mit dem Empfänger sehr gute Erfahrungen gemacht, anders als mit dem um einiges billigeren XY-5MV. Ich weiß nicht, ob ich von der Fernbedienung bzw FHEM Rechtecksignale kriege, aber ich vermute, dass die von mir erfassten Daten ziemlich nahe an der Realität sind.

Gemessen wird "raw", das heißt ich beobachte nur die Amplitude des 433MHz-Signals und messe die Zeit (in Mikrosekunden, vermute ich), die zwischen HIGH und LOW (im Sinne von 433 MHz) liegt. Das ist also eine Folge von natürlichen Zahlen, die meist mit einem Synchronisationssignal beginnt und dann eine logischen Folge von HIGHs und LOWs beschreibt. Diese raw-Daten sind der Ausgangspunkt für jede weitere Kodierung und Verarbeitung, wenn diese nicht identisch sind, gibt es nachher nur Probleme. Hier nun das Ergebnis. Man sieht, dass es einen Unterschied von bis zu 20%, teilweise 35% zwischen FHEM und Brennenstuhl bei den Zeitdauern gibt. Und diese Unterschiede sind stabil, ich habe mehrfach gemessen:

Code Auswählen Erweitern


--------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------
FERNBEDIENUNG ORIGINAL BRENNENSTUHL
--------------------------------------------------------------------------------------------------------------------------------

Decimal: 1315153 (24Bit) Binary: 000101000001000101010001 Tri-State: 0FF00F0FFF0F PulseLength: 302 microseconds Protocol: 1
Raw data: 9412,292,924,292,920,292,924,904,316,292,924,900,328,284,924,288,928,288,928,288,928,288,924,900,384,224,988,836,384,228,984,840,380,228,984,840,380,232,980,844,380,840,376,844,376,844,372,844,376,

Decimal: 1315153 (24Bit) Binary: 000101000001000101010001 Tri-State: 0FF00F0FFF0F PulseLength: 302 microseconds Protocol: 1
Raw data: 9416,288,924,292,928,288,924,900,324,284,924,900,320,284,932,284,932,284,928,284,932,284,932,892,380,232,980,844,372,236,980,844,372,240,976,848,372,236,976,848,372,848,376,844,372,848,372,848,368,

Decimal: 1315072 (24Bit) Binary: 000101000001000100000000 Tri-State: 0FF00F0F0000 PulseLength: 301 microseconds Protocol: 1
Raw data: 9416,292,924,292,924,292,924,900,316,292,920,904,316,284,932,284,932,284,932,280,936,280,932,888,372,236,976,848,372,240,972,852,368,240,976,848,368,244,972,852,368,852,372,848,368,852,364,852,368,

Decimal: 1315153 (24Bit) Binary: 000101000001000101010001 Tri-State: 0FF00F0FFF0F PulseLength: 302 microseconds Protocol: 1
Raw data: 9408,296,920,296,916,296,920,904,312,296,920,904,316,244,968,244,972,244,968,248,968,248,968,856,352,260,952,872,352,256,952,872,348,264,948,876,348,260,952,872,348,872,344,876,348,872,344,876,344,

Decimal: 1315153 (24Bit) Binary: 000101000001000101010001 Tri-State: 0FF00F0FFF0F PulseLength: 302 microseconds Protocol: 1
Raw data: 9408,296,920,296,920,296,920,900,320,288,928,896,324,244,972,244,968,248,968,244,968,248,968,856,348,264,952,872,348,260,952,872,348,264,952,872,348,260,952,872,348,872,348,872,348,872,348,872,344,

Decimal: 1315153 (24Bit) Binary: 000101000001000101010001 Tri-State: 0FF00F0FFF0F PulseLength: 302 microseconds Protocol: 1
Raw data: 9408,288,928,288,928,284,932,892,328,280,936,884,344,252,960,252,964,252,964,252,968,248,960,864,348,260,952,876,344,264,948,876,344,264,952,876,344,264,948,876,344,876,344,876,344,876,340,880,344,

Decimal: 1315153 (24Bit) Binary: 000101000001000101010001 Tri-State: 0FF00F0FFF0F PulseLength: 302 microseconds Protocol: 1
Raw data: 9408,284,932,284,932,280,932,888,336,272,944,876,348,252,964,252,964,252,964,252,960,256,960,864,344,264,952,872,344,264,948,876,348,264,948,876,344,264,952,876,344,872,344,876,344,876,348,872,344,


--------------------------------------------------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------------------
FHEM SIGNALduino und IT-Modul
--------------------------------------------------------------------------------------------------------------------------------

Decimal: 1315153 (24Bit) Binary: 000101000001000101010001 Tri-State: 0FF00F0FFF0F PulseLength: 247 microseconds Protocol: 1
Raw data: 7792,212,772,252,776,204,780,708,328,188,796,700,284,228,792,192,792,192,788,236,788,196,788,708,280,232,788,196,788,236,788,708,280,192,788,708,320,192,784,712,280,232,788,196,784,240,784,712,304,

Decimal: 1315153 (24Bit) Binary: 000101000001000101010001 Tri-State: 0FF00F0FFF0F PulseLength: 247 microseconds Protocol: 1
Raw data: 7752,252,732,252,776,204,780,708,328,188,792,700,288,228,792,192,788,196,792,232,792,192,788,704,288,232,784,196,788,236,788,708,276,196,788,708,316,196,784,712,276,236,784,200,784,240,784,712,300,

Decimal: 1315153 (24Bit) Binary: 000101000001000101010001 Tri-State: 0FF00F0FFF0F PulseLength: 247 microseconds Protocol: 1
Raw data: 7752,252,772,212,772,212,776,712,324,188,792,704,280,232,792,192,788,236,788,196,788,200,784,708,316,204,780,196,788,236,784,712,276,236,744,752,276,196,784,712,312,200,784,200,780,248,780,712,340,

Decimal: 1315153 (24Bit) Binary: 000101000001000101010001 Tri-State: 0FF00F0FFF0F PulseLength: 247 microseconds Protocol: 1
Raw data: 7784,340,684,188,800,180,780,708,324,192,792,704,320,192,788,196,788,196,824,200,788,196,788,708,316,196,784,200,788,236,784,712,276,196,784,712,316,196,784,712,276,236,784,200,780,244,784,712,296,

Decimal: 1315153 (24Bit) Binary: 000101000001000101010001 Tri-State: 0FF00F0FFF0F PulseLength: 248 microseconds Protocol: 1
Raw data: 7796,212,772,248,776,208,780,708,284,232,788,708,280,192,788,236,788,196,788,236,788,196,784,712,280,232,788,196,784,200,784,712,316,196,784,712,276,236,784,712,276,236,784,200,784,200,780,716,344,

Decimal: 1315153 (24Bit) Binary: 000101000001000101010001 Tri-State: 0FF00F0FFF0F PulseLength: 248 microseconds Protocol: 1
Raw data: 7756,248,776,208,780,244,780,708,288,184,796,700,324,188,792,192,792,232,792,196,788,236,788,704,284,192,788,236,784,200,784,708,280,232,788,708,280,232,748,748,280,192,788,240,784,200,780,712,348,


Auffällig ist auch, dass die Kodierung identisch ist und die Abweichungen stabil bei ca 20% liegen (mit wenigen Ausnahmen). Wenn die Funksteckdosen hohe Toleranzen aufweisen, sollte das im Grunde gehen. Aber wenn die Signalstärke gering ist oder was auch immer, kommt es natürlich zu einem Ausfall.

Nun meine Frage an die SIGNALduino-Intertechno-Profis. Kann man diese Zeitunterschiede in den Modulen anpassen? Kann man im Zweifel ein Attribut setzen, das veränderbar ist und das dann auf die Brennenstuhl/Conrad/was-auch-immer-Funksteckdosen anwenden kann? Ich würde gern stabilere Ergebnisse haben, aber dazu müssen die Zeiten zwischen LOW und HIGH einfach identischer sein. Schon die Synchronisationssignale unterscheiden sich erheblich.

PS Hier auch eine genauere Beschreibung von Intertechno, die zu meiner Analyse passt: https://wiki.pilight.org/doku.php/elro_hc

[Sidey]

Du kannst den Basistakt in jedem IT device separat einstellen.
Ich glaube das Attribut nennt sich ITClock.

Wenn Du mit Fhem und dem Signalduino sendest, dann kannst Du dir mit verbose5 auch anzeigen, wie lange ein Pegel gehalten wird.

Grüße Sidey

Gesendet von meinem Nexus 5 mit Tapatalk

[andies]

Du kannst den Basistakt in jedem IT device mit  ITClock einstellen.

Das hatte man mir schon mal vorgeschlagen. Irgendwie ging das aber nicht, weil ich nicht wusste, was genau das ist. In der commandref steht es nur bei CUL:

Set the IT clock for Intertechno V1 protocol. Default 250.

und mehr findet sich da nicht. Ist die ITClock das, was ich oben als "PulseLength" gemessen habe? Dann sollte ich 302 nehmen. Probiere ich mal, danke!

[Ralf9]

Für den Signalduino steht die Ermittung des ITClock in der Device specific help des Signalduino

Gruß Ralf

[andies]

Das reicht nicht. Ich habe jetzt die ITClock umgestellt, die raw-Daten sind aber immer noch unterschiedlich. Oben steht FHEM, unten die Fernbedienung. Zwar ist Pulselength identisch, aber eben die raw-commands nicht:

Code Auswählen Erweitern

FHEM

Decimal: 1312081 (24Bit) Binary: 000101000000010101010001 Tri-State: 0FF000FFFF0F PulseLength: 303 microseconds Protocol: 1
Raw data: 9348,308,912,308,916,264,916,888,340,292,928,884,296,292,928,252,928,296,924,296,924,256,924,296,928,300,916,888,296,292,928,884,336,256,924,884,340,56,268,188,60,44,112,356,32,84,76,408,52,

Decimal: 1312081 (24Bit) Binary: 000101000000010101010001 Tri-State: 0FF000FFFF0F PulseLength: 302 microseconds Protocol: 1
Raw data: 9384,308,916,264,916,304,920,884,304,288,928,884,340,248,928,296,928,292,924,256,924,300,924,296,924,256,924,884,340,292,928,884,296,292,924,888,104,32,820,24,116,112,584,124,2908,28,164,168,308,

Decimal: 1312081 (24Bit) Binary: 000101000000010101010001 Tri-State: 0FF000FFFF0F PulseLength: 299 microseconds Protocol: 1
Raw data: 9384,324,900,320,904,276,904,900,324,304,916,896,288,304,912,308,912,268,912,308,916,304,916,268,912,308,912,896,328,264,916,896,324,304,876,896,328,304,912,896,288,304,912,308,912,272,908,900,332,

----------------------------------------------------------------------------------------------------------------------------------
FERNBEDIENUNG

Decimal: 1312081 (24Bit) Binary: 000101000000010101010001 Tri-State: 0FF000FFFF0F PulseLength: 302 microseconds Protocol: 1
Raw data: 9432,272,944,268,948,268,944,880,344,264,952,872,348,228,984,232,980,232,988,228,984,232,984,232,360,248,964,860,360,252,964,860,356,252,964,860,356,256,960,864,356,864,356,860,360,860,356,864,356,

Decimal: 1312081 (24Bit) Binary: 000101000000010101010001 Tri-State: 0FF000FFFF0F PulseLength: 303 microseconds Protocol: 1
Raw data: 9428,284,928,284,932,284,928,892,332,280,936,888,332,280,932,280,936,280,936,280,932,284,932,888,328,284,932,892,332,276,936,888,332,276,936,888,332,280,936,888,332,888,328,888,332,888,336,884,332,

Decimal: 1312081 (24Bit) Binary: 000101000000010101010001 Tri-State: 0FF000FFFF0F PulseLength: 302 microseconds Protocol: 1
Raw data: 9448,268,948,268,948,264,952,872,348,260,956,868,352,268,944,272,944,272,944,272,948,264,948,876,336,272,944,880,336,276,940,884,336,272,944,880,336,272,944,884,332,884,340,880,336,884,336,884,336,




[Sidey]

Der richtige Wert für Clock wird dir vom Signalduino im Log ab Verbose 4 angezeigt.

Der liegt so um die 280.

Wie Du die 302 gemessen hast weiss ich nicht. Vom Signalduino  sind das zumindest keine Meldungen.

Es kann auch sein, dass deine Steckdosen sich nicht exakt an das IT Protokoll halten.

Grüße Sidey

Gesendet von meinem Nexus 5 mit Tapatalk

[andies]

Wenn bei der Messung mit rc-Switch die pulselength übereinstimmt, dann muss ich doch den richtigen Wert gewählt haben?

Es kann sein, dass sich die Brennenstuhldosen nicht an das IT-Protokoll halten, das ist möglich. Obwohl die nahe genug dran liegen. Dann müsste man aber das Protokoll anpassen. Ist das dann eher eine Sache für den Sinalduino oder für IT.pm?

Wozu dient denn pulselength genau: wird beim senden dann diese pulselength benutzt, um die Zeit zwischen LOW und HIGH zu beeinflussen? Bei mir geschieht das nämlich gerade nicht, vielmehr sind die Zeiten anscheinend unabhängig davon. Ich dachte, wenn ich pulselength ändere, ändern sich die raw-Daten entsprechend linear mit. Dann würde nämlich alles stimmen!


Gesendet von iPad mit Tapatalk Pro

[andies]

PS Meine Angaben kommen von rc-Switch, link siehe oben.


Gesendet von iPad mit Tapatalk Pro

[KölnSolar]

bei IT(Derivat) wird immer x*pulselength mit X=1,3 gesendet. Eine binäre 0 zB. 1*pulselength high, 3*p low, 1*p high, 3*p low,
und da liegt möglicherweise das Problem: die gemessenen Daten weichen stark vom Verhältnis 1/3 ab

[andies]

Und gibt es Möglichkeiten, ohne Veränderung der originalen FHeM-pm das Sendeverhalten zu beeinflussen (Attribut o.Ä.)?

[KölnSolar]

Beim Signalduino kann ich dazu nichts sagen, sondern nur spekulieren. In der (a)culfw ist es nicht einstellbar, vermutlich auch nicht beim Signalduino  Macht aber irgendwie auch keinen Sinn. Wenn die Pulslängen so stark variieren, ist das "Käse". Dann lässt sich ja gar nicht mehr das Protokoll erkennen(Empfang). Zum Senden müsste es ja evtl. mit der raw-Funktionalität als workaround klappen, wenn sich keine "normal" funktionierende pulslength/ITclock je Dose finden lässt.

[Ralf9]

PS Meine Angaben kommen von rc-Switch, link siehe oben.

Ohne die raw Nachrichten vom Signalduino wird Dir wahrscheinlich niemand helfen können.

Die raw Nachrichten sehen ungefähr so aus:

Code Auswählen Erweitern

MS;P0=-1112;P1=334;P2=1107;P3=-418;P4=-11307;D=14102310101010101010101010101010101010102310231023;CP=1;SP=4;R=80;O;

Gruß Ralf

[andies]

Ich kümmere mich um die SIGNALduino-raw-Daten, sobald ich zu Hause bin. Bis dahin schon mal folgendes: Ich habe mich oben vermutlich falsch ausgedrückt. Die Pulslängen der Fernbedienung sind stabil und variieren nicht, wenn ich sie mit rc-switch messe. Sie sind nur nicht identisch den Werten, die ich beim IT-Modul aus FHEM beobachte. Das mit den 1,3 kann ich (fast) bestätigen, ich habe mir die Durchschnitte ausgerechnet und in der Tat sind alle Längen (Sync, 0 und 1 jeweils bestehend aus einem LOW sowie einem HIGH) um den Faktor 1,2 länger.

Ich habe mir zudem den SIGNALduino-Code angeschaut, aber ich blicke da nicht wirklich durch (ich wollte mal CAME in den SIGNALduino einbauen, musste dann aber leider auch aufgeben). Mir scheint es so, dass die entscheidende Stelle, an der das Sendeverhalten des SIGNALduino definiert wird, diese hier ist:

Code Auswählen Erweitern


"3" => {
name => 'itv1',
id => '3',
one => [3,-1],
zero => [1,-3],
#float => [-1,3],
#not full supported for later use
sync => [1,-31],
clockabs=> -1, #auto
format => 'twostate', not used now
usw  }

Ich lese das so, dass das Signal aus one and zero besteht (was der Fall ist) und beide Signale jeweils durch ein HIGH und ein LOW definiert werden, wobei das erste HIGH/LOW die Länge von 1*clockabs/pulselength und das zweite LOW/HIGH die Länge von 3*clockabs/pulselength hat.

Und an der Stelle steige ich bereits aus. Denn:

• 
  Wieso ist clockabs automatisch? Ist das nicht gleich der pulselength? Und wenn es automatisch ist, sollte doch ein Faktor 1,3 oder 1,2 überhaupt kein Problem darstellen?


• Das mit der 3:1 stimmt bei mir nur bedingt, ich messe bei den gesendeten Daten aus FHEM ein Verhältnis von ca 210:780 (zero) und ca 710:300 (one). In keinem Fall aber passt das zu einer pulselength von 250 oder so, eher 300.


• Und wenn ich im IT-device in FHEM eine pulselength von 300 einstelle und mir anschaue, was FHEM sendet, passt das noch weniger, weil dann auf einmal HIGH/LOWs (am Ende der Sequenz) mit einer Einzellänge von unter 100 auftauchen?!

[andies]

Hier nun die SIGNALduino-Daten, wenn ich die Brennenstuhl-FB drücke. Im Logfile (verbose 5) steht

Code Auswählen Erweitern

2017-06-24 14:12:12 IT IT_0FF00FF0FF off
2017-06-24 14:12:12 SIGNALduino sduino UNKNOWNCODE i14145F
2017-06-24 14:12:12 IT IT_0FF00FF0FF off
2017-06-24 14:12:12 SIGNALduino sduino UNKNOWNCODE i14155F
2017-06-24 14:12:13 IT IT_0FF00FF0FF off
2017-06-24 14:12:13 SIGNALduino sduino UNKNOWNCODE i14155F
2017-06-24 14:12:14 IT IT_0FF00FF0FF off
Im Gerät selbst findet sich die raw-Message

Code Auswählen Erweitern

Internals:
   00         f0
   DEF        0FF00FF0FF 0F F0
   IODev      sduino
   LASTInputDev sduino
   MSGCNT     4
   NAME       IT_0FF00FF0FF
   NR         146
   STATE      off
   TYPE       IT
   XMIT       0ff00ff0ff
   XMITdimdown 00
   XMITdimup  00
   XMITon     0f
   sduino_DMSG i141454
   sduino_MSGCNT 4
   sduino_RAWMSG MS;P1=-929;P2=276;P3=873;P4=-348;P5=-9447;D=25212121342134212121212134213421212134213421342121;CP=2;SP=5;R=17;O;
   sduino_RSSI -65.5
   sduino_TIME 2017-06-24 14:12:14
   Code:
     1          0ff00ff0ff
   Readings:
     2017-06-18 11:59:24   protocol        V1
     2017-06-24 14:12:14   state           off
Attributes:
   IODev      sduino
Ich habe dann mehrere dieser raw-Messages aufgezeichnet:

Code Auswählen Erweitern


MS;P1=-929;P2=276;P3=873;P4=-348;P5=-9447;D=25212121342134212121212134213421212134213421342121;CP=2;SP=5;R=17;O;
MS;P1=268;P2=-948;P3=894;P4=-328;P6=-9461;D=16121212341234121212121234123412121234123412341212;CP=1;SP=6;R=8;O;
MS;P0=275;P3=-944;P5=869;P6=-355;P7=-9433;D=07030303560356030303030356035603030356035603560303;CP=0;SP=7;R=1;O;
MS;P1=270;P2=-934;P4=886;P5=-369;P6=-9452;D=16121212451245121212121245124512121245124512451212;CP=1;SP=6;R=13;O;
Könnt Ihr damit was anfangen?

[Ralf9]

Wie viele Känale hat Deine Brennenstuhl-FB?

Kannst Du mal für jeden Kanal für on und off jeweils die folgenden Daten posten? (aus dem log mit verbose 4)

Code Auswählen Erweitern

MS;P1=-929;P2=276;P3=873;P4=-348;P5=-9447;D=25212121342134212121212134213421212134213421342121;CP=2;SP=5;R=17;O;
sduinoD IT: message "i141454" (7)
sduinoD IT: msgcode "0FF00FF0FFF0" (12) bin = 000101000001010001010100