Fernotron Steuer-Code an RolloTube von Fa. Rademacher senden

Begonnen von klausdor, 01 Mai 2013, 13:55:17

Vorheriges Thema - Nächstes Thema

zwiebert

#210
@Ralf9

Danke. Habs gerade getestet und funktioniert sehr zuverlässig, auch wenn das aktuelle dev-r33 Modul wohl noch (verkürzte) Byte-dmsg statt der Bits mit den Fs erzeugt.

@alle
Damit vereinfacht sich das ganze Prozedere auf folgendes:

- auf letzte dev-r33 version updaten (bei mir ist es v3.3.3-dev_15.09)
- 10_Fernotron.pm nach /opt/fhem/FHEM/ kopieren und mit reload 10_Fernotron laden
- (Ein SIGNALduino Gerät definieren falls noch nicht vorhanden: define sduino SIGNALduino /dev/ttyUSB0@57600)
- "developId      => 'm'," auskommentieren in /opt/fhem/FHEM/lib/signalduino_protocols.hash beim Fernotron protocol
- attr sduino development m82   (wenn SIGNALduino mit diesem Namen definiert wurde)
- SIGNALduino firmware 3.3.2.1 rc2 rc3 oder neuer flashen

- STOP Taste der 2411 Zentrale einige Sekunden festhalten
- Jetzt sollte nach dem aktualisieren des FHEM Webinterfaces das Gerät "scanFerno" automatisch erscheinen (autocreate)
- als STATE wird der empfangene Code angezeigt:  a=801234 g=1 m=2 c=stop
Dabei ist "a" die ID deiner 2411, "g" die Gruppe (G) und "m" der Empfänger (E)
- Jetzt könnte man Rolladen nach dem gleichen Muster  definieren:
    define rollo_11 a=801234 g=1 m=1
    define rollo_G1_E2 Fernotron a=801234 g=1 m=2
    define rollo_Kueche Fernotron a=801234 g=1 m=3
    define rollo_Wohnzimmer Fernotron a=801234 g=1 m=4
    define rollo_Alle Fernotron a=801234
    define rollo_Ergeschoss Fernotron a=801234 g=1
    define rollo_Obergeschoss Fernotron a=801234 g=2

10_Fernotron.pm ist zu finden auf https://github.com/zwiebert/tronferno-fhem im Unterordner modules.


mfg Bert

Ralf9

Zitat- SIGNALduino firmware 3.3.2.1 rc2 flashen
Die Version ist 3.3.2.1 rc3

Zitat- "developId      => 'm'," auskommentieren in /opt/fhem/FHEM/lib/signalduino_protocols.hash beim Fernotron protocol
Das auskommentieren ist nicht notwendig.
Attr development m82
ist ausreichend

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

zwiebert

#212
@Ralf9

hab das erfolgreich getestet mit der modifizierten 00_SIGNALduino.pm
https://raw.githubusercontent.com/Ralf9/RFFHEM/master/FHEM/00_SIGNALduino.pm

Hab damit auch versucht eine empfangene DMSG mit SendMsg und copy/paste zu senden. Dachte dank der Fs sind ja alle Daten enthalten.

Ich vermute aber, dass da in meiner Protokolldefinition die Info fehlt, dass einer Nachricht noch ein 'F' und 7 Schwingungen +400/-400us vorangehen.  Fürs Senden wär das ja wichtig, dass das irgendwo definiert ist?

IIRC waren sync und start für MU nicht gedacht und sonst finde ich nix in der doku.

Wenn P für eine +400/-400 Schwingung steht, dann würde eine MSG beim senden aussehen:

P82#FPPPPPPPF0000000001F0000000010F...

entsprechend der Timings für die RAW messages:

my $p_string = 'P0=400;P1=-400;P2=-3200;P3=-800;P4=800;';
my $d_pre_string = '01010101010101';    # preamble
my $d_stp_string = '02';                # stop comes before each preamble and before each word
my $d_dt0_string = '41';                # data bit 0 (/..long..\short)
my $d_dt1_string = '03';                # data bit 1 (/short\..long..)



mfg Bert

zwiebert

Zitat von: fhemfreund am 30 August 2018, 18:56:50
Sobald es dann über das Tronferno Modul geht werde ich es aus Fhem testen. Danke schoneinmal für deine Mühe, das möglich zu machen.

Hab das nun einige Zeit getestet mit einem FHEM-Sever auf einem alten Netbook im Dauerbetrieb und Tronferno auf ESP8266, und das hing wirklich alle Nase lang offenbar im TCP-Server.   

Hab nun erstmal das FHEM Modul geändert in ein zweistufiges Modul, dass es nun auch über FHEMs DevIo Modul sich verbindet. Hat auch noch den Vorteil, dass es sowohl mit WLAN als auch über USB funktioniert.

Bin außerdem noch vom ESP8266 auf den ESP32 gewechselt. Der läuft jetzt tagelang ohne Probleme an WLAN oder USB. 

mfg Bert

Ralf9

ZitatWenn P für eine +400/-400 Schwingung steht, dann würde eine MSG beim senden aussehen:

P82#FPPPPPPPF0000000001F0000000010F...

Wenn Du das
pause          => [1,-1],
in die Protokolldefinition einfügst

und in der sub SIGNALduino_Set($@)
hier  'F'=> "float" einfügst
my %bitconv = (1=>"one", 0=>"zero", 'D'=> "float", 'F'=> "float", 'P'=> "pause");

dann ergibt

2018-09-27 20:00:45.483 SIGNALduino sduinoRXB sendMsg P82#FPPPPPPPF0000000001F0000000010F
2018.09.27 20:00:45.588 4 : sduinoRXB SendrawFromQueue: msg=SR;R=1;P0=400;P1=-800;P2=800;P3=-400;P4=-3200;D=04030303030303030423232323232323232301042323232323232323012304;



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

zwiebert

@Ralf9

Danke. Hab das mal versuchsweise so in mein Modul eingbaut, und funktioniert. Dann kann ich das 'raw' Senden bald auch rauswerfen, so wie vorher den 'raw' Empfang.

mfg Bert





Ralf9

#216
mich würde interessieren wie stabil die SIGNALduino firmware 3.3.2 rc oder 3.3.2.1 rc äuft, insbesondere ob durch das viele senden mit der Zeit das freeram weniger wird.

Ich habe bei mir inzwischen eine uptime von 141 Tagen, ich sende nur sehr wenig.

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

fhemfreund

Zitat von: zwiebert am 27 September 2018, 20:10:24
Hab das nun einige Zeit getestet mit einem FHEM-Sever auf einem alten Netbook im Dauerbetrieb und Tronferno auf ESP8266, und das hing wirklich alle Nase lang offenbar im TCP-Server.   

Hab nun erstmal das FHEM Modul geändert in ein zweistufiges Modul, dass es nun auch über FHEMs DevIo Modul sich verbindet. Hat auch noch den Vorteil, dass es sowohl mit WLAN als auch über USB funktioniert.

Bin außerdem noch vom ESP8266 auf den ESP32 gewechselt. Der läuft jetzt tagelang ohne Probleme an WLAN oder USB. 

mfg Bert

Habe die Tage mal Zeit gefunden auf den ESP32 zu wechseln. Schaut soweit ganz gut aus. Was mir aufgefallen ist: ich kann leider in Fhem via Tronferno-Modul keinen Repeat Parameter übergeben z.B.:


define RolladenBalkonTuerT Tronferno g=1 m=1 r=3


bekomme folgende Fehlermeldung:


unknown argument r=3 in define


In der seriellen Konsole funktioniert das via


send g=1 m=1 c=down r=3;


einwandfrei.

Andreas

zwiebert

@fhemfreund

Im Modul 10_Ferntoron.pm hab ich wohl dafür das Attribut "repeats".  Werd den betreffenden Code bei nächster Gelegenheit nach 10_Tronferno.pm übernehmen.  Muss ich vergessen haben.

Danke für die Rückmeldung.

-Bert

fhemfreund

Zitat von: zwiebert am 18 Dezember 2018, 11:11:19
@fhemfreund

Im Modul 10_Ferntoron.pm hab ich wohl dafür das Attribut "repeats".  Werd den betreffenden Code bei nächster Gelegenheit nach 10_Tronferno.pm übernehmen.  Muss ich vergessen haben.

Danke für die Rückmeldung.

-Bert

Danke für das Update. Habe es mal gerade eingespielt. Geht soweit gut. Eine Frage dazu noch: In der seriellen Konsole sieht man, sobald ein Kommando via Fhem gesendet wird. z.B.:


tcp_io_getc: Connection reset by peer
tcps: disconnected. 0 client(s) still connected
modify io to serial
modify io to tcp
192.168.xxx.xxx:58709 connected (1 clients)
reply@82: ok
U:position: a=0x00xxxxac g=1 m=2 p=0;


allerdings sieht man die 'c' und 'r' Parameter dabei nicht - ist das so korrekt?

Andreas

zwiebert

#220
@fhemfreund

Ist alles korrekt so.  Das send-Kommando kann man nicht in der Konsole sehen, weil das CLI selber kein Echo erzeugt.

Die Meldung "U:position..." gibt nur die Position des Rolladens zurück, also ob offen oder geschlossen. Also p=0 für zu und p=100 für offen und p=50 für Sonnenposition.  Eine U:position Meldung wird immer erzeugt wenn diese sich durch Kommando oder Timer ändert oder beim neuverbinden zwischen FHEM und tronferno-mcu.

Um zu überprüfen, dass das Kommando mehrfach wiederhohlt wird, kann man im CLI die Bytes anschauen welche gesendet werden.  Ist eine Meldung der Form "S:0x80,0x...". Diese kann man nur sehen wen man die "verbosity" erhöht mit dem CLI-Kommando:

config verbose=1;

-Bert



Ralf9

Hallo Bert,

hast Du vor das 10_Ferntoron.pm noch weiter zu entwickeln?

Beim Testen sind mir zwei Dinge aufgefallen:

Es fehlt das Attribut IODev
$hash->{AttrList} = 'IODev repeats:0,1,2,3,4,5';

Das Senden ist fest auf send raw fest eingestellt.
Das Senden mit sendmsg müsste inzwischen auch funktionieren.

Ich habe zum Testen mal was gesendet.
Aus
sendMsg P82#DPPPPPPPD0000000101D0000000110D0100100000D0100100011D0010110001D0010110010D1101100000D1101100011D1010100001D1010100010D0110111100D0110111111
wird
SR;R=1;P0=400;P1=-800;P2=800;P3=-400;P4=-3200;D=0403030303030303042323232323232301230104232323232323230101230423012323012323232323042301232301232323010104232301230101232323010423230123010123230123040101230101232323232304010123010123232301010401230123012323232301040123012301232323012304230101230101010123230423010123010101010101;

Das SR habe ich dann in eine MU-Nachricht gewandelt
MU;P0=-32001;P1=400;P2=-3200;P3=-400;P4=800;P5=-800;CP=1;D=01213131313131313124343434343434315431512434343434343431515431243154343154343434343124315434315434343151512434315431515434343151243431543151543431543121515431515434343434312151543151543434315151215431543154343434315121543154315434343154312431515431515151543431243151543151515151515;e;

Mit der MU-Nachricht habe ich mit einem dummy sduino simuliert und es wurde der folgende dispatch zum Ferntoron Modul durchgeführt.
Starting demodulation (Signal: (?:15|43|12){100,} Pos 17) length_min_max (100..3360) length=132
dispatch P82#F0000000101F0000000110F0100100000F0100100011F0010110001F0010110010F1101100000F1101100011F1010100001F1010100010F0110111100F0110111111


Damit dies funktioniert, ist die dev-r33 version notwendig.
Die aktuelle Version meiner firmware ist V 3.3.2.1-rc8
https://forum.fhem.de/index.php/topic,82379.msg744554.html#msg744554

Die Ausgabe der sehr langen MU-Nachrichten funktioniert z.Zt. bei der offiziellen Entwicklerversion dev-r33 nur bei unkomprimierten Nachrichten (Mred=0).
get sduino raw CEO
get sduino raw CDR

Ein get config ergibt dann folgendes:
config: MS=1;MU=1;MC=1;Mred=0;MuNoOverflow=1;....


attr sduino development m82
ist nicht mehr notwendig, es reicht aus 82 in die whitelist einzutragen.

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

zwiebert

Hallo Ralf,

danke für die Hinweise. Dass IODev Attribut kannte ich nicht. Damit hätte man sich die Patcherei bei "stable" sparen können, wenn man Empfang nicht benötigt,,,

Hab das jetzt mal geändert, so dass sendMsg wenn möglich benutzt wird. Hab es mit SIGNALduino-Modul v3.3.3-dev_30.12 erfolgreich getestet.

Werde an dem Modul sicherlich bei Gelegenheit noch einiges machen.  Wollte es auch mal richtig aufräumen sobald die dev-3.3.3 Änderungen in stable angekommen sind

mfg Bert

zwiebert

@Alle

...aufgrund näherer Beschäftigung mit FHEM nun ein paar Änderungen für meine Fernotron Module:

Die Module werden jetzt korrekt mit FHEMs update Kommando installiert und aktualisiert. Siehe: https://github.com/zwiebert/tronferno-fhem/blob/master/README-de.md

Ich habe für die Entwicklerversion von SIGNALduino nun ein eigenes 10_Fernotron.pm Modul wo das nun überflüssige RAW-Send entfernt wurde.  Weitere Verbesserungen werde ich idR nur noch in diesem Modul machen.

Das Fernotron-Modul für SIGNALduino-dev  erzeugt nun über das Gerät scanFerno Reading-Events, so dass man alle Fernotron Sender und Sonnensensoren allgemein in Notify oder DOIF Geräten verwenden kann. Um z.B. mit einem überzähligen Fernotron Handsender eine Lampe zu dimmen.

mfg Bert

fhemfreund

#224
@Bert,

ist denn geplant das Ganze auch mit einem SignalESP lauffähig zu bekommen? Oder geht das ev. sogar schon?

Übrigens: die MCU Version funktioniert bei mir nun schon seit einer ganzen Weile ohne Probleme.

Wenn das mit einem SignalESP ginge, könnte weitere HW eingespart werden (habe schon einen SignalESP im Einsatz).

Andreas