Autor Thema: Bug bei Brennenstuhl/Intertechno?  (Gelesen 988 mal)

Offline andies

  • Sr. Member
  • ****
  • Beiträge: 634
Bug bei Brennenstuhl/Intertechno?
« am: 22 Januar 2017, 16:37:57 »
Ich habe schon einen Thread eröffnet, aber dort so viel neben der Spur geschrieben, dass ich hier einen neuen Thread eröffne. Ich möchte gern Brennenstuhl Funksteckdosen mit FHEM schalten. Dazu habe ich sie angelernt, bzw das haben die guten Dinger schon selbst getan. Internals lauten
DEF 0FF00FFF0F 0F F0
IODev CUL
NAME Steckdose_A
NR 24
STATE on
TYPE IT
XMIT 0ff00fff0f
XMITdimdown 00
XMITdimup 00
XMIToff f0
XMITon 0f

Readings
protocol V1 2017-01-21 19:56:19
state on 2017-01-22 16:25:31

Mit der Fernbedienung lassen sie sich bedienen, nicht aber mit FHEM (bzw nur einmal). Also habe ich mit die raw-signals mal angeschaut, die von der FB sowie von FHEM gesendet werden. Dazu habe ich pilight-raw (https://wiki.pilight.org/doku.php/praw) verwendet. Diese Software gibt die Zeitdifferenz in Mikrosekunden aus, die zwischen HIGH und LOW liegen.

Nun gibt es gravierende Differenzen zwischen dem, was die FB und was FHEM machen. Das kann aber nicht sein, wenn das Protokoll angeblich Brennenstuhl kennt.

FB (und das steht auch in dem Forumeintrag für Brennenstuhl von pilight, siehe https://wiki.pilight.org/doku.php/elro_hc) liefert folgende Zeitdifferenzen:
433gpio:  289 913 298 921 292 914 905 317 289 925 898 319 287 929 285 928 285 925 289 926 287 928 285 927 286 927 898 324 282 928 896 322 286 926 897 324 285 928 894 324 283 931 283 930 284 927 896 323 287 9404 -#: 50
Pilight sagt auch, dass die Zeitdifferenzen etwa 320 und 960 betragen. Schlussendlich ergibt das einen logischen Code von 01100 01111 01 und das passt sowohl zum Hauscode als auch zum Gerätecode und zum On-Schaltbefehl.

Wenn ich bei FHEM drücke, sehe ich erstmal völlig andere Zeitdifferenzen; keine Ahnung, ob das relevant ist (400 statt 360 und 1200 statt 960):
433gpio:  476 1192 421 1331 408 1261 1243 431 393 1277 1323 423 400 1291 371 1276 404 1257 478 1276 393 1270 1233 432 398 1352 1233 435 398 1296 1212 426 398 1351 399 1269 398 1276 1226 435 406 1343 399 1274 396 1270 1237 425 401 13196 -#: 50
Aber auch der logische Code ändert sich, ich sehe jetzt
01100 11101 01und das ist beim Gerätecode definitiv falsch.

Kann mir jemand sagen, wo ich jetzt was ändern muss, damit das klappt?
FHEM 5.8 auf RaspPi3 (Raspbian jessie 4.9.35-v7+); Perl: v5.20.2
SIGNALduino (433 MHz) und miniCUL (868 MHz, derzeit noch ungenutzt)
mehrere Brennenstuhl-IT, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor

Offline RomanticBoy83

  • Jr. Member
  • **
  • Beiträge: 67
Antw:Bug bei Brennenstuhl/Intertechno?
« Antwort #1 am: 22 Januar 2017, 16:48:17 »
Ich nutze als Protokoll "intertechno_switch"
Ich kann mich auch daran erinnern einmal gelesen zu haben, dass es zwei verschiedene Protokolle von denen gibt.

Offline andies

  • Sr. Member
  • ****
  • Beiträge: 634
Antw:Bug bei Brennenstuhl/Intertechno?
« Antwort #2 am: 22 Januar 2017, 16:55:28 »
Ja, es gibt version 1 und version 3. Version 3 hat rolling code, was hier definitiv nicht der Fall ist. Aber daran kann es nicht liegen. Dann dürfte es ein Bug bei intertechno_switch sein.
FHEM 5.8 auf RaspPi3 (Raspbian jessie 4.9.35-v7+); Perl: v5.20.2
SIGNALduino (433 MHz) und miniCUL (868 MHz, derzeit noch ungenutzt)
mehrere Brennenstuhl-IT, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor

Offline Puschel74

  • Hero Member
  • *****
  • Beiträge: 9787
Antw:Bug bei Brennenstuhl/Intertechno?
« Antwort #3 am: 22 Januar 2017, 17:54:59 »
Wenn du dir sicher bist einen "Bug" gefunden zu haben - verschieb den Beitrag doch in das passende Unterforum.
Dort kann dir vermutlich schneller und besser geholfen werden.
Cubietruck als Server mit DBLog
CUNO für FHT80B und FS20, HM-Lan, RasPi mit CUL433 für Somfy-Rollo (F2F), RasPi mit I2C(LM75) (F2F), RasPi für Panstamp+Vegetronix +SONOS(F2F)
Ich beantworte keine Supportanfragen per PM! Bitte im Forum suchen oder einen Beitrag erstellen.

Offline bjoernh

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 725
Antw:Bug bei Brennenstuhl/Intertechno?
« Antwort #4 am: 22 Januar 2017, 21:32:50 »
Werden denn die Dosen in Fhem automatisch angelegt?
Wenn ja, sollte es doch eigentlich passen.
Die Zeiten sind denke ich nicht so kritisch. Der Chip welcher in den günstigen Dosen verbaut ist ist da relativ tolerant.
Du kannst die Zeiten aber noch mit dem Attribut ITfrequency anpassen. Standard ist hier 420. Wenn Du also auf 320 gehst, geht auch der lange Impuls im Verhältnis runter.

Offline andies

  • Sr. Member
  • ****
  • Beiträge: 634
Antw:Bug bei Brennenstuhl/Intertechno?
« Antwort #5 am: 22 Januar 2017, 22:37:26 »
Danke für den Hinweis. Ich habe die ITfrequency geändert - keine Reaktion. Und ja, die Steckdosen wurden automatisch erkannt, haben aber nur einmal geschaltet. Ich habe mit dem Verändern erst begonnen, als die Dosen aussetzten.

PS ITFrequency ist doch die Sendefrequenz. Warum sollte die 320MHz sein? Auf der Steckdose steht eindeutig 433.92!
« Letzte Änderung: 24 Januar 2017, 13:53:11 von andies »
FHEM 5.8 auf RaspPi3 (Raspbian jessie 4.9.35-v7+); Perl: v5.20.2
SIGNALduino (433 MHz) und miniCUL (868 MHz, derzeit noch ungenutzt)
mehrere Brennenstuhl-IT, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor

Offline Ralf9

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1745
Antw:Bug bei Brennenstuhl/Intertechno?
« Antwort #6 am: 23 Januar 2017, 00:08:56 »
Es sind in letzter Zeit Steckdosen aufgetaucht wo mehr als eine Nachricht gesendet wird, evtl müssen bei diesen auch mehr als eine Nachricht gesendet werden damit diese schalten

Siehe auch hier:
Ich habe nun noch einmal gespielt und die Codes zum probieren geändert.
Wenn ich den Magnetkontakt an den Sender halte, bekomme ich folgende Eventeintrag:
2017-01-19 20:26:01 CUL nanoCUL UNKNOWNCODE i50514c
2017-01-19 20:26:01 CUL nanoCUL UNKNOWNCODE i505140


Entferne ich den Kontakt kommt folgendes:
2017-01-19 20:26:34 CUL nanoCUL UNKNOWNCODE i505143
2017-01-19 20:26:34 CUL nanoCUL UNKNOWNCODE i505140


Per Autocreate sind 2 Device angelegt worden.
Ich kann mit dem einem Device auch die Steckdose ausschalten aber nicht wieder an. Und irgendwie greift das dann auch in die Übermittlung von der Fernbedienung ein. Dieser reagiert dann erst nach 2-3 mal wieder.
Wie bekomme ich da ein Zusammenspiel hin?

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
SIGNALduino

Offline andies

  • Sr. Member
  • ****
  • Beiträge: 634
Antw:Bug bei Brennenstuhl/Intertechno?
« Antwort #7 am: 24 Januar 2017, 13:54:32 »
Ja, ich bekomme auch zwei Signale. Ich habe mir doch die Raw-Codes angeschaut. Die sind komplett anders als im Wiki und in anderen Foren (beispielsweise pilight) beschrieben. Die Zeitdauer, in der HIGH und LOW gesendet werden, stimmen nicht überein. Kann das ein Problem sein? Und dann bin ich mir nicht sicher, ob die Codes übereinstimmen, dazu müsste ich aber wissen, die FHEM sie anspricht.
FHEM 5.8 auf RaspPi3 (Raspbian jessie 4.9.35-v7+); Perl: v5.20.2
SIGNALduino (433 MHz) und miniCUL (868 MHz, derzeit noch ungenutzt)
mehrere Brennenstuhl-IT, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor

Offline Wichtel

  • Jr. Member
  • **
  • Beiträge: 76
Antw:Bug bei Brennenstuhl/Intertechno?
« Antwort #8 am: 24 Januar 2017, 19:56:31 »
Vermutlich war der "ITClock" gemeint.
Dort passen solche Zahlenwerte besser. Mit dem ITClock wird die Impulslänge verändert, falls es in deiner CUL-Firmwareversion schon implementiert ist.

Offline andies

  • Sr. Member
  • ****
  • Beiträge: 634
Antw:Bug bei Brennenstuhl/Intertechno?
« Antwort #9 am: 25 Januar 2017, 18:37:51 »
Danke, ITClock habe ich geändert. Ist jetzt 320 und das müsste ja nun angeblich stimmen. Es gibt aber nach wie vor keine Reaktion der Steckdosen. Was nicht verwundert, wenn die binär gesandte Sequenz falsch ist (siehe oben meine Angaben zum Haus- und Gerätecode). Kann ich denn die Codes auch händisch einstellen?
FHEM 5.8 auf RaspPi3 (Raspbian jessie 4.9.35-v7+); Perl: v5.20.2
SIGNALduino (433 MHz) und miniCUL (868 MHz, derzeit noch ungenutzt)
mehrere Brennenstuhl-IT, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor

Offline andies

  • Sr. Member
  • ****
  • Beiträge: 634
Antw:Bug bei Brennenstuhl/Intertechno?
« Antwort #10 am: 29 Januar 2017, 21:32:22 »
Ich habe ein wenig weiter geforscht und mit pilight-raw die eigentlichen Codes angeschaut. Wenn ich die Brennenstuhl-Fernbedienung drücke, bekomme ich relative klare Signale. L entspricht (gemittelt über insgesamt 16 pulsetrains) einer Länge von 292, H entspricht einer Länge von 922. Das ergibt ein Verhältnis von 3,15:1, bischen viel (üblich sind wohl 3). Der Footer ist im Durchschnitt 9430 lang.

Ich habe in meiner Steckdose die Dips wie folgt eingestellt: Hauscode 01100 (wobei 0 für on, oben und 1 für off, unten steht), der Gerätecode der Steckdose, die ich mir anschaue, ist 01111 (also Steckdose A, wenn man so will).

Kodiert man 0 für LHLH und F für LHHL, dann funkt die Fernbedienung 0FF00 0FFFF F0, zuzüglich FOOTER. Das passt, da der Hauscode 0FF00 ist und der Gerätecode in der Tat 0FFFF. F0 steht für off, on ist dann 0F (beides getestet).

Wenn ich dagegen in FHEM ein "define test IT 0FF000FFFF F0 0F" anlege (mit ITClock 320, model itswitch), dann ist (gemittelt über fünf pulsetrains, mehr kriege ich da nicht) ein LOW von 300 und ein HIGH von 877. Gerade HIGH weicht ganz schön ab, egal. Der Footer ist L+9123. Irritierend ist, dass ich ITClock 320 angegeben habe, aber nur 300 kriege?! Ist denn die CUL wirklich so ungenau? 

Gesendet wird dann 0FF00 0FFFF 0F für off und 0FF00 0FFFF F0 für on, also wie gefordert. Dann kann nur die Abweichung der ITClock relevant sein, etwas anderes fällt mir nicht ein.

« Letzte Änderung: 19 März 2017, 16:54:00 von andies »
FHEM 5.8 auf RaspPi3 (Raspbian jessie 4.9.35-v7+); Perl: v5.20.2
SIGNALduino (433 MHz) und miniCUL (868 MHz, derzeit noch ungenutzt)
mehrere Brennenstuhl-IT, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor

Offline andies

  • Sr. Member
  • ****
  • Beiträge: 634
Antw:Bug bei Brennenstuhl/Intertechno?
« Antwort #11 am: 19 März 2017, 17:14:44 »
Ich verstehe die Welt nicht mehr. Jetzt, nachdem ich mir einen raw-Befehl zusammengebastelt habe, klappt alles. For the record, falls es mal wieder nicht gehen sollte, wie folgt vorgehen:

Angenommen, man hat eine Brennenstuhl-Steckdose mit Haus- und Gerätecode 0FF00 0FFFF F0  (erste fünf sind der Hauscode, nächsten fünf der Gerätecode, danach kommt "on"; hier wäre also Steckdose A eingestellt; wie oben gesagt steht dabei 0 für "on", "oben" und 1 für "off", "unten"). Dann übersetzt sich das in folgende Zahlenfolge. Aus 0 wird 292 -922 292 -922 und aus F wird 292 -922 922 -292. Damit lautet der entsprechende raw-Befehl, der auch den Footer (04) enthält

set sduino raw SR;;R=3;;P0=292;;P1=-292;;P2=922;;P3=-922;;P4=-9430;;D=03030321032103030303030303210321032103210303032104;;
Analog kann man dann die anderen Steckdosen aus- und anschalten.
« Letzte Änderung: 19 März 2017, 22:16:43 von andies »
FHEM 5.8 auf RaspPi3 (Raspbian jessie 4.9.35-v7+); Perl: v5.20.2
SIGNALduino (433 MHz) und miniCUL (868 MHz, derzeit noch ungenutzt)
mehrere Brennenstuhl-IT, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor

Offline Wetterhexe

  • New Member
  • *
  • Beiträge: 39
  • FHEMinistin
Antw:Bug bei Brennenstuhl/Intertechno?
« Antwort #12 am: 19 März 2017, 22:00:40 »
Ich hab die Dinger auch im Einsatz (RCS 1000 N mit IT v1)

Die Definition schaut bei mir so aus, wobei am Mäuseklavier Schalter nach oben=0 bzw. unten=F ist (also so wie du schon beschrieben hast).
define WZlichtstehlampeC IT 0F00F0FFFF 0F F0
Was mir auffällt ist daß bei dir die Definitionen für den Schaltbefehl andersrum sind (F0 0F statt 0F F0)

Lassen sich übrigens auch mit dem TRX schalten, type ist AB400D.