Fernotron Steuer-Code an RolloTube von Fa. Rademacher senden

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

Vorheriges Thema - Nächstes Thema

froonk

Hallo zusammen,

ich habe meine guten Rademacher Fernotron über die Anleitung auf GitHub in FHEM integriert, was schon lange super läuft.
https://github.com/dasoho/fernotron-control
Jetzt, wo es so warm ist, kommt der Wunsch wieder auf, die Rolladen Mittags nur halb runter zu fahren.

Hier wurde schon die Frage gestellt, ob ich GenShellSwitch benötige, der nur up und down kennt oder ob ich direkt die consolen commands eingeben kann?

Wenn ich "/home/pi/Fernotron/FernotronRemote.sh 1 1 s" direkt in FHEM eingebe, dann kann ich damit auch das Stop command absetzen.

Leider schaffe ich es nicht, das in FHEM zu integrieren.

Wie kann ich die den Stop Befehlt am cleversten einrichten?

Usecase:
If 11am && Temp>25 then WZ1 + WZ2 down
5 Sekunden später das stop Signal senden

Besten Dank.

Pythonf


froonk

Das Modul Rollo schaue ich mir an, danke dir. Denke aber, hier benötige ich auch irgendwie die stop Funktion. Gibt es konkrete Beispiele, wie fernotron-control mit dem ROLLO-Modul aussieht?

froonk


fhemfreund

@Bert (zwiebert)

Danke erstmal für deine Arbeit! :-)

habe mal beide Versionen (Tronferno und Fernotron) ausprobiert.
Die MCU Variante (Tronferno) hat sofort 1a funktioniert.

Mit der SignalDuino Version (habe das Ganze mit einem NanoCul + CC1101 probiert) bekomme ich aber leider kein Senden (=Rollo Steuerung) hin.
Der Empfang = scannen via ScanFerno funktioniert einwandfrei und zeigt mir brav die decodierte ID und auch alle Raw-Messages an. (sogar wenn ich von der MCU sende und auch natürlich von der 2411). Beim Senden jedoch reagiert aber kein Rollo - im Log sehe ich, dass Raw Messages an den Signalduino gehen - kann aber leider nicht erkennen, ob diese korrekt sind.

Welche Versionen vom Signalduino + Fhem hattest du denn seinerzeit bei deinen erfolgreichen Tests verwendet? Gibt es ev. noch 'Stellschrauben', an denen ein erfolgreiches Senden hängt?

Die Signalduino FW ist:


V 3.3.2-rc2 SIGNALduino cc1101 - compiled at Jun 1 2018 23:56:22


Die Fhem Modul Versionen sind:


00_SIGNALduino.pm    16624 2018-04-15 18:58:49Z rudolfkoenig
90_SIGNALduino_un.pm 12722 2016-12-06 21:03:14Z mrsidey


Andreas

zwiebert

#200
Hallo Andreas.

ich hab es gerade getestet mit einer FHEM Neuinstallation. Alles hat funktioniert.  FHEM Module waren dieselben Versionen wie du schriebst.   Nur die SIGNALduino Firmware ist anders: Version 3.3.1-rc7 für Nano (Atmega 328p). Konnte keine 3.3.2-rc2 zum Download finden und hab auch keine CC1101 Hardware.  Könnte also an CC1101 oder an der neueren Version liegen.  Vielleicht könntest du die 3.3.1 probieren? Oder 3.3.0. die funktioniert bei mir auch.  Wo finde ich die 3.3.2-rc2 Dateien?

https://github.com/RFD-FHEM/SIGNALDuino/releases
SIGNALDuino_nano.hex


(Hab beim testen auch gemerkt: Mit den Modulen aus dev-33 geht 10_Fernotron,pm nicht. Schon das patchen klappt nicht)

(10_Fernotron.pm setzt übrigens beim Senden "sduino" als Device-Name für SIGNALduino vorraus ... aber das ist hier wohl nicht das Problem)

mfg Bert

fhemfreund

Hallo Bert,

sorry für die späte Antwort. Die 3.3.2-rc2 Dateien sind unter


https://github.com/Ralf9/SIGNALDuino/tree/dev-r332_cc1101/firmware


zu finden.

Glaube mittlerweile auch, dass meine Probleme an der CC1101 Kombination liegen.

Werde daher die ESP/MCU Lösung mit FS1000A verwenden, da sie bei mir 1a funktioniert. Allerdings habe ich ab und zu Hänger vom ESP. Würde das ganze gerne per externem Watchdog mit Attiny lösen (habe ich so z.B. bei meinem LaCrosse Gateway erfolgreich im Einsatz). Dazu bräuchte ich aber einen GPIO am ESP, den ich von FHEM aus (als keep alive) ansteuern könnte. Gäbe es die Möglichkeit, dass du deine MCU Firmware dahingehend so erweiterst, dass das ginge?

Andreas

zwiebert

#202
@fhemfreund

Die neuste Nano-Version dort ist SIGNALduino_nano_332rc1.hex.   Hab das mal geflasht und auch bei mir funktioniert damit das senden nicht mehr.  Im FHEM Logfile steht, das Kommando wäre zu lang (und außerdem (?) nicht unterstützt).  Ist ja auch recht lang. Beim Empfangen schneidet der SIGNALduino  auch hinten was weg, weil es so lang ist. Und zwar auch bei den alten Versionen.

Die alten Versionen bis 3.3.1 funktionieren beim Senden.  Vermutlich auch für CC1101.

Log mit Firmware 3.3.2-RC1

2018.08.25 23:13:36 1: Rolladen_22: send: 0x80, 0x12, 0x34, 0x29, 0x25
2018.08.25 23:13:36 4: sduino SendrawFromQueue: msg=SR;R=2;P0=400;P1=-400;P2=-3200;P3=-800;P4=800;D=0201010101010101024141414141414103410302414141414141410303410241034141034141414141024103414103414141030302414103410303414141030241410341030341410341020341410341034141410302034141034103414103410203410341410341414103020341034141034141034102414103410341414141410241410341034141410303;
2018.08.25 23:13:36 4: sduino/msg READ: cmd to long!
2018.08.25 23:13:36 4: sduino/msg READ: Received answer (cmd to long!) for sendraw does not match ^S(R|C|M);
2018.08.25 23:13:36 4: sduino/msg READ: Unsupported command
2018.08.25 23:13:36 4: sduino/msg READ: Received answer (Unsupported command) for sendraw does not match ^S(R|C|M);
2018.08.25 23:13:38 4: sduino/HandleWriteQueue: sendraw no answer (timeout)
2018.08.25 23:13:38 4: sduino/HandleWriteQueue: nothing to send, stopping timer




Log mit Firmware 3.3.1-RC7

2018.08.25 23:40:27 1: Rolladen_22: send: 0x80, 0x12, 0x34, 0x39, 0x25
2018.08.25 23:40:27 3: Rolladen_22: raw: SR;R=2;P0=400;P1=-400;P2=-3200;P3=-800;P4=800;D=0201010101010101024141414141414103410302414141414141410303410241034141034141414141024103414103414141030302414103410303414141030241410341030341410341020341410303034141414102034141030303414103030203410341410341414103020341034141034141034102414103414103414141410241410341410341410303;
2018.08.25 23:40:27 4: set sduino raw SR;R=2;P0=400;P1=-400;P2=-3200;P3=-800;P4=800;D=0201010101010101024141414141414103410302414141414141410303410241034141034141414141024103414103414141030302414103410303414141030241410341030341410341020341410303034141414102034141030303414103030203410341410341414103020341034141034141034102414103414103414141410241410341410341410303;

2018.08.25 23:40:27 4: sduino SendrawFromQueue: msg=SR;R=2;P0=400;P1=-400;P2=-3200;P3=-800;P4=800;D=0201010101010101024141414141414103410302414141414141410303410241034141034141414141024103414103414141030302414103410303414141030241410341030341410341020341410303034141414102034141030303414103030203410341410341414103020341034141034141034102414103414103414141410241410341410341410303;
2018.08.25 23:40:28 4: sduino/msg READ: SR;R=2;P0=400;P1=-400;P2=-3200;P3=-800;P4=800;D=0201010101010101024141414141414103410302414141414141410303410241034141034141414141024103414103414141030302414103410303414141030241410341030341410341020341410303034141414102034141030303414103030203410341410341414103020341034141034141034102414103414103414141410241410341410341410303;
2018.08.25 23:40:28 4: sduino/read sendraw answer: SR;R=2;P0=400;P1=-400;P2=-3200;P3=-800;P4=800;D=0201010101010101024141414141414103410302414141414141410303410241034141034141414141024103414103414141030302414103410303414141030241410341030341410341020341410303034141414102034141030303414103030203410341410341414103020341034141034141034102414103414103414141410241410341410341410303;
2018.08.25 23:40:28 4: sduino/HandleWriteQueue: nothing to send, stopping timer



Wegen Tronferno:

Wenn der ESP hängt, dann funktionerts wohl doch nicht so 1a?  :D

Weiß nicht ob das so ideal zuverlässig ist mit dem Tronferno-ESP8266 über WLAN.  Der SIGNALduino hat da den Vorteil, dass er über USB angeschlossen ist (was natürlich auch mit Tronferno ginge).

Man könnte ihm sicherlich leicht ein Kommando beibringen, welcher GPIO-Pins setzt und abfragt. Aber ob das gut ist über WLAN ständig Kommandos zu senden?  Eigentlich sollte der ESP keine Hänger haben. Hat ja eigentlich einen Watchdog eingebaut. Ich werde das Tronferno-Modul mal selber ein paar Tage testen mit FHEM.  Hab hier den Tronferno-ESP im Dauerbetrieb seit Monaten und steuer ihn mit einer Android-App an.  Funktioniert eigentlich ohne Hänger, nur gelegentlich (wirklich selten) bekomme ich mal keine Verbindung, aber nach einigen Sekunden geht es wieder.  Könnte sein, dass der ESP dann gerade einen Hänger hat und einen Neustart durchführt.  Ich sollte da mal ein Logfile  implementieren, dass man sieht wie oft er neu startet.

mfg Bert


fhemfreund

Bert,

Zitat
Man könnte ihm sicherlich leicht ein Kommando beibringen, welcher GPIO-Pins setzt und abfragt.

Das wäre top!!

Zitat
Aber ob das gut ist über WLAN ständig Kommandos zu senden?  Eigentlich sollte der ESP keine Hänger haben. Hat ja eigentlich einen Watchdog eingebaut.

Laut meinen Erfahrungen sind zyklische Trigger über LAN ok - wäre also für mich kein Problem. Zusätzlich hat deine MCU Lösung den Vorteil, dass ich Kommandos von 2 FHEM Instanzen senden kann - bei der Signalduino Lösung müsste ich halt schon 2 Stück haben.

Andreas


Ralf9

ZitatDie neuste Nano-Version dort ist SIGNALduino_nano_332rc1.hex.   Hab das mal geflasht und auch bei mir funktioniert damit das senden nicht mehr.
Ich habe bei meiner 332 die Länge des Sendekommandos auf ca 300-350 Zeichen begrenzt. Ich konnte mir nicht vorstellen, daß es so lange Sendekommandos geben könnte.
Ich kann es in der nächsten Version z.B. auf 350 oder 400 erhöhen. Je mehr Zeichen ich für Sendekommandos reserviere, umso kleiner wird der freie Speicher. Ein freier Speicher von 400 müsste noch ok sein.

Zitat(Hab beim testen auch gemerkt: Mit den Modulen aus dev-33 geht 10_Fernotron,pm nicht. Schon das patchen klappt nicht)
In der dev-33 hat sich inzwischen recht viel geändert, z.B. ist die ProtokollID 77 inzwischen durch ein anderes Protokoll belegt.

Kann die 10_Fernotron.pm auch bei den aktuellen Funkrolläden der Fa Rademacher verwendet werden?

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

#205
@Ralf9

Zitat von: Ralf9 am 26 August 2018, 23:22:27
Ich kann es in der nächsten Version z.B. auf 350 oder 400 erhöhen.
340 Zeichen sollte als Limit ausreichen für die normlen 6 Byte (120bit) Fernotron Kommandos.  Das 14-Byte (280bit) Kommando zum stellen der internen Uhr bräuchte deutlich mehr Zeichen (800?), aber das muss man ja auch nicht über FHEM machen.

Vielleicht könntest du auch beim Empfang was ändern, so dass die Fernotron Kommandos komplett empfangen werden und nicht am Ende einige  Zeichen in der RAW Message fehlen.


Zitat von: Ralf9 am 26 August 2018, 23:22:27
Kann die 10_Fernotron.pm auch bei den aktuellen Funkrolläden der Fa Rademacher verwendet werden?
10_Fernotron.pm  funktioniert leider nicht mit den aktuellen Rademacher Motoren. Das unidirektionale 443 MHz Fernotron  wurde vom bidirektionalen 886 MHz DuoFern abgelöst.


Zitat von: Ralf9 am 26 August 2018, 23:22:27
In der dev-33 hat sich inzwischen recht viel geändert, z.B. ist die ProtokollID 77 inzwischen durch ein anderes Protokoll belegt.
Wenn es nur die Protokoll ID wäre. Blicke beim neuen 00_SIGNALduino.pm  noch überhaupt nicht durch.   Werden die Protokolle immer noch auf folgende Art definiert?



    "77" => ## Fernotron shutters and light switches   
+ #MU;P0=-32001;P1=435;P2=-379;P4=-3201;P5=831;P6=-778;D=01212121212121214525252525252521652161452525252525252161652141652521652521652521614165252165252165216521416521616165216525216141652161616521652165214165252161616521652161416525216161652161652141616525252165252521614161652525216525216521452165252525252525;CP=1;O;
+ # the messages received are usual missing 12 bits at the end for some reason. So the checksum byte is missing.
+ # Fernotron protocol is unidirectional. Here we can only receive messages  sent from controllers to shutters.
+ {
+ name         => 'Fernotron',
+ id           => '77',   # protocol number
+ one          => [1,-2], # on=400us, off=800us
+ zero         => [2,-1], # on=800us, off=400us
+ float        => [1,-8], # on=400us, off=3200us. each 10bit word has one [1,-8] in front
+ clockabs     => 400,    # 400us
+ preamble     => 'P77#', # prepend our protocol number to converted message
+ clientmodule => 'Fernotron', #
+ length_min   => '100', # actual 120 bit (12 x 10bit words to decode 6 bytes data), but last 20 bit are for checksum and truncated by SIGNALduino firmware
+ length_max   => '3360', # 3360 bit (336 x 10bit words to decode 168 bytes data) for full timer message
+       },




mfg Bert
     

Ralf9

Ich habe dazu ein neues issues aufgemacht:
https://github.com/RFD-FHEM/RFFHEM/issues/257

ZitatVielleicht könntest du auch beim Empfang was ändern, so dass die Fernotron Kommandos komplett empfangen werden und nicht am Ende einige  Zeichen in der RAW Message fehlen.
Dies wird etwas aufwändiger. Ich habe eine Idee wie man es hinbekommen kann.

ZitatWenn es nur die Protokoll ID wäre. Blicke beim neuen 00_SIGNALduino.pm  noch überhaupt nicht durch.   Werden die Protokolle immer noch auf folgende Art definiert?
Die Protokolle sind in
/lib/signalduino_protocols.hash
ausgelagert worden.

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

#207
@Ralf9

Danke. Werd dann mal das Fernotron Modul für dev-33 anpassen und testen.


@fhemfreund

Zitat von: fhemfreund am 25 August 2018, 23:52:16
Laut meinen Erfahrungen sind zyklische Trigger über LAN ok - wäre also für mich kein Problem. Zusätzlich hat deine MCU Lösung den Vorteil, dass ich Kommandos von 2 FHEM Instanzen senden kann - bei der Signalduino Lösung müsste ich halt schon 2 Stück haben.

In der neuesten Verision der Tronferno Firmware lassen sich die GPIO 12-15 vom User ansteuern. Bisher aber nur im Terminal CLI und noch nicht über das Tronferno FHEM-Modul.

Zuerst muss ein GPIO einmalig konfiguriert werden als Ein- oder Ausgang. Diese Einstellung wird im Flash gespeichert und bei jedem Reboot erneut geladen.


Beispiele:

#GPIO-12 definieren und initialen Ausganspegel festlegen.   

config gpio12=1;  # als Ausgang und eingeschaltet
config gpio12=0;  # als Ausgang und ausgeschaltet
config gpio12=i;  # als Eingang
config gpio12=p;  # als Eingang mit Pullup-Widerstand
config gpio12=d restart=1;  # zurück auf normaleinstellung

#GPIO-12 setzen und auslesen

mcu gpio12=?; # Pegel auslesen (ergibt 0 oder 1)
mcu gpio12=0; # Ausgangspegel 0 (Low) setzen
mcu gpio12=1; # Ausgangspegel 1 (High) setzen
mcu gpio12=t; # Ausgangspegel wechseln (toggle)


mfg Bert

fhemfreund

Bert,

Zitat
In der neuesten Verision der Tronferno Firmware lassen sich die GPIO 12-15 vom User ansteuern. Bisher aber nur im Terminal CLI und noch nicht über das Tronferno FHEM-Modul.

top :D !

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.

Andreas

Ralf9

Zitat340 Zeichen sollte als Limit ausreichen für die normlen 6 Byte (120bit) Fernotron Kommandos.  Das 14-Byte (280bit) Kommando zum stellen der internen Uhr bräuchte deutlich mehr Zeichen (800?), aber das muss man ja auch nicht über FHEM machen.

Vielleicht könntest du auch beim Empfang was ändern, so dass die Fernotron Kommandos komplett empfangen werden und nicht am Ende einige  Zeichen in der RAW Message fehlen.

Hier gibt es eine neue firmware in der ich das Limit auf 350 erhöht habe. Ich habe auch eingebaut, daß sehr lange MU-Nachrichten empfangen werden können.
https://forum.fhem.de/index.php/topic,82379.msg836541.html#msg836541

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