Bug bei Brennenstuhl/Intertechno?

Begonnen von andies, 22 Januar 2017, 16:37:57

Vorheriges Thema - Nächstes Thema

andies

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 01
und das ist beim Gerätecode definitiv falsch.

Kann mir jemand sagen, wo ich jetzt was ändern muss, damit das klappt?
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

RomanticBoy83

Ich nutze als Protokoll "intertechno_switch"
Ich kann mich auch daran erinnern einmal gelesen zu haben, dass es zwei verschiedene Protokolle von denen gibt.

andies

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

Puschel74

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.
Zotac BI323 als Server mit DBLog
CUNO für FHT80B, 3 HM-Lan per vCCU, 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.

bjoernh

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.

andies

#5
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!
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

Ralf9

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:
Zitat von: Thoffi1978 am 20 Januar 2017, 10:55:49
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 HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

andies

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

Wichtel

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.

andies

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

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

#11
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.
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

Wetterhexe

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.

NoPlan12

Hallo,
hier war zwar schon lange keiner mehr, aber ich will es trotzdem mal versuchen.
Ich habe ein 3er Pack Brennstuhldosen mit der Bezeichnung RCR1000N und die dazu gekaufte Fernbedienung mit der Bezeichnung RCS1000SN, weiterhin Fhem auf Raspi3 im Anfangsstadium und einen CUL868 von Busware. Leider ist es mir bisher nicht gelungen die Dinger in Fhem richtig einzubauen. Ich hatte gehofft, daß Euer Thema mir weiter hilft. War aber leider nicht so. Könnt Ihr mir aber sagen, ob es irgendwo mal so eine Schritt für Schritt Beschreibung für die Installation solcher Brennstuhldosen gibt? Ach und noch was. Wenn die Funksteckdosen in Fhem integriert sind, geht dann die FB trotzdem noch? und kann es dann immer noch passieren, daß der Nachbar andauernd meinen Kodi und TV ausschhaltet?

Gruß Jens 

andies

Probier mal
defmod Steckdose_B IT 0FF00F0FFF 0F F0
attr Steckdose_B IODev sduino
attr Steckdose_B ITclock 290
attr Steckdose_B fm_type lamp
attr Steckdose_B model itswitch

Wobei du deinen Gerätecode und dein IODev eingeben musst. Geht bei mir. Und ja, FB geht unabhängig, FHEM ist praktisch eine zweite FB. Und wenn du den Code nimmst wie der Nachbar, kann der auch schalten.
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