FHEM Forum

Hi,

wir haben schon seit längerem Elero Combio 868/915 Rolladenmotoren mit zugehöriger Elero Fernbedienung bei uns im Haus verbaut. Ich habe mir kürzlich einen Raspberry geholt und auch schon FHEM installiert. Der CUL ist jetzt gestern angekommen und jetzt würde ich gerne auch die Rolladen über FHEM steuern.

Ich frage mich jetzt nur, wie ich die Empfänger der Rolladenmotoren meinem FHEM vorstelle.

Es muß sich um selbstlernende Empfänger handeln, da ich als ich die Handsender damals initiiert habe einfach den Strom von den Rolladenkästen genommen habe und danach dann mit den Sendern zu jedem einzelnen Rolladen mußte um die beiden aneinander zu "gewöhnen".

Wie bringe ich jetzt FHEM bzw den CUL noch in diese Konstellation?

ciao
Martin

FHEM bekommt die Signale mit wenn du die Rolladen mit der Fernbedieung einmal bedienst.
Dann laden diese Geräte im Ordner unsorted.

Danach rename etc. durchführen, wie mit den gewöhnlichen Aktoren.

Habe auch Elero Rolladenmotoren mit Proline 2 Empfängern. Die FHEM, die sonst mit CUL jede Baumarktfernbedienung einfängt, erzeugt noch nicht einmal einen Eintrag im Logfile, dass ein unbekanntes Gerät empfangen wurde.
Selbstverständlich wurde auch kein Empfänger automatisch angelegt.

Recherche im Netz nach dem Protokoll von Elero (wird wohl auch bei anderen Herstellern verwendet) führte zu keinem Ergebnis.

Einzige Mögilchkeit die ich sehe ist: Eine Fernbedienung zerlegen, die Bauteile recherchieren und anhand der Datenblätter die Datensignale mit Soundkarte aufzeichnen, bevor sie auf die 868 MHz moduliert werden. Dann haben wir mit der FHEM und Rohdatensenden eine chance.

Meiner bisherigen Einschätzung nach ist das Protokoll bidirektional. Die Acknowledgement Nachrichten könnten anfangs bequem ignoriert werden. Es ist kein rollierender Code in Verwendung wie bei Auto-Funkschlüsseln, daher halte ich ein Aufzeichnen und Replay für möglich.

Hat jemand eine Proline 2-kompatible Fernbedieung wie die Tempotel Monotel? Ein Bild im Netz konnte ich nicht finden, die das geöffnete Gehäuse zeigt.

Bin dankbar für zielführende Kommentare.

Hi,

ich habe zwei TempoTel 2 und zwei SoloTel 2. Was hast du konkret vor?

Gruß
A.P.

Hallo A.P.,

ich möchte gerne über FHEM Rolladen per Kanal auf, ab und gerne auch auf Lüftungsposition fahren.
Hast du mit FHEM und einem CUL bereits Kontakt mit deinen ELERO Transceivern aufgenommen?

Habe zur Zeit eine Bestellung laufen, einen DVB-T-Stick zum Software Defined Radio zu misbrauchen, damit ich so für ca. 10 EUR und einem PC mit SDR# einen Spektrumanalyzer habe. Ich erhoffe mir so ein Aufzeichnen der Signale, die dann über den CUL (so meine Hoffnung) wiedergegeben werden kann. Das Acknowledgement bei der bidirektionalen Kommunikation kann ich gerne ignorieren.

Viele Grüße
vitolinker

Hi zusammen,

hat jemand nun schon einen Elero - Rollladen gesteuert.

Leider führt mich Google immer zu irgendwelchen Ergebnissen die dann genauso Enden wie dieser Artikel, ergebnislos. Ich hatte jedoch gedacht mit FHEM ist alles möglich.

Danke an alle Poweruser die mit uns Newbies ihr Wissen teilen.

LG

kirschroter_lump

Hi,

hab dank nicht aktivierter Benachrichtigung erst jetzt gesehen, das ihr geantwortet habt.

Also bei mir hat sich auch noch kein Gerät automatisch bei FHEM angemeldet und die Rolladen werden täglich gesteuert.

Hattet ihr zwischenzeitlich noch Erfolg beim Ansteuern?
Ansonsten bleibt wohl wirklich nur der Weg des Reverse Engineering der Funksignale oder Elero durch andere Steuerung auszutauschen :)

ciao
Martin

Hi, auch ich wäre an den Einbindung von Elero in FHEM interessiert.
Gibt es jemanden, der sowas realisieren kann?
VG,
Marc

Push!

Servus. Hab' (leider) das gleiche 'Problem' sprich diverse Fenster mit entsprechenden Motoren bzw. Steuerung.
Wäre super wenn die auch im FHEM eingebunden werden könnten.

Ahoj
Cray

Hi
Wir bräuchten wohl erstmal Informationen von elero zu deren Funkprotokoll. Ohne das, müsste man alles selber decodieren.

Wenn man die Informationen hat, könnte man schauen ob ein anderes Modul zB Intertechno ähnlich ist und es anpassen. Falls nicht müsste es komplett selber implementiert werden.
Hat jemand von euch schon mal bei elero angefragt ?
Ciao
Martin

Uiii.

Ich sehe soeben, elero hat jetzt ein eigenes Produkt für die Steuerung im Portfolio.

Zitat: ,,Die Centero von elero verbindet die Vorteile des bidirektionalen Funksystems ProLine 2 nun auch mit der komfortablen und intuitiven Bedienung Ihrer Haustechnik per Smartphone oder Tablet."

Siehe http://www.centero-elero.com bzw. http://www.elero.de/de;presse;fachmedien;d:4052.htm

Da bin ich ja mal gespannt, ob die das Protokoll offenlegen bzw. ob das kompatibel mit den CULs / meinem CUL (CC1101) ist. Laut Bedienungsanleitung arbeitet der Transmitter auf einer Frequenz von 868 / 915 MHz.

Zumal die elero Lösung nicht gerade günstig zu erwerben sein wird. Die Preise liegen wohl so um die 480 € für die Steuerzentrale und 140 € für den Transmitter!?

Ahoj
Cray

Hi Cray
Fragst du bei denen an ?
Ciao
Martin

Bei elero nachfragen bringt nichts, da diese den Zugang mittels App für eine jährliche Gebühr verticken.
Der einzige Weg geht nur mit dem elero Stick für centero, welcher am Raspi oder NUC angebunden werden muss.
Centero basiert auf einem Debian Server, auf welchen aber nur via Webinterface (Admin/Password) zugegriffen werden kann.

Hallo,

habe für mich und meine 12 Elero Rolladen eine einigermaßen praktikable Lösung gefunden. :D

Das Bild in Anlage zeigt meinen Testaufbau an meinem Test - BBB.

Ich habe an einem UniTec 868 die Steuerleitungen Auf, Ab, Stop, und Masse herausgeführt und kann damit über die GPIO
und Mini-Relais meine Rolladen in Gruppen steuern.
Das ist zwar keine optimale Lösung aber besser als garnichts. Ausserdem gibt es den UniTec 868 relativ günstig.
Ich werde die Ost, Süd, West Seite meines Hauses jeweils mit einer UniTec 868 ansteuern.
Die bisherigen Fernbedienungen und Einzelsteuerungen sind hiervon unberührt.


Gruss Billy

Hallo,

@Billy: sieht ja schön aus.
Wenn du einen Sender schon offen hast, ist es vielleicht praktiabel die Datenleitung abzugreifen die an den 868MHz Transceiver führt. So könntest du die Signale mit einem Logikanalyzer (vielleicht gibt es auch ein Skript, das die Millisekunden der Pegel einfach nur loggt) oder sogar gleich als seriellen Bitstrom einlesen. Bei letzterem würde ich mit der Bitrate und Stopbits experimentieren.
Zur Feststellung der Bitrate kann auch ein guter Multimeter dienen: Dutycycle von 50% weist auf eine gute Verteilung der 0 und 1 Bits hin und Frequenzmesser ist eine untere Schranke für die Bitrate. Genau 50% Dutycycle weist auf Manchastercodierung hin.

So könntest du mit nur drei Leitungen alle deine Rolläden mit einer UniTech 868 steuern, in dem due die Signale die du aufgezeichnet hast, direkt so als Replay an den Sender gibst. Diese Transceiver bekommst du beim Chinesen deines Vertrauens bereits für wenige US$.

Leider sind meine Versuche mit einem Software Defined Radio aufgrund der hohen Datenrate nicht von Erfolg gekrönt gewesen. Da hast du bessere Chancen direkt an der Datenleitung vom Sender.

Hoffe, du hast die anderen drei UniTechs noch nicht bestellt ;-)

@vitolinker

Deine Vorschläge zum Auslesen der Datenleitung finde ich äusserst interessant. Übersteigen jedoch meine
Kenntnisse, Fähigkeiten und Ausrüstung mit Messgeräten als Privatier.

Ich bin eigentlich mit dem jetzigen Ergebnis sehr zufrieden , da ich auch die Zwischenpositionen und Lüftungspositionen
anfahren kann.

Wenn ich mehr Ahnung hätte, würde ich deine Vorschläge mit dem up-sender-invio-868 realisieren.
http://www.friedrich-schroeder.de/produkte/funksteuerungen/elero-proline/up-sender-invio-868

Ist zwar etwas teurer aber vermutlich zugänglicher.

Gruß Billy

Hallo Billy,

ich denke, das ist nicht schwieriger als das, was du bereits geschafft hast.
Es gibt wohl ein Modul auf der Platine des UniTech, das den Sender darstellt. Ich vermute,e s gibt vier pins: +5V, Masse, DataIn, DataOut.
Hier einfach mal jeweils die DataIn/Out Pins an jeweils ein GPIO Port klemmen und über eine Schleife im Skript sehr oft den Status und die Systemzeit mit abfragen.
Damit wüssten wir schon mehr.

Viel Spass

wenn ich mir die Frequenz und die Prozeduren bei elero so ansehe könnte man meinen dass das
Übertragungsprotokoll vielleicht z-wave ist. Hat jemand einen z-wave USB-Stick oder eine
z-wave raspberry Modul zum ausprobieren ?

Ich habe mir ein z-wave USB-Stick  bestellt und werde das mal mit einem Raspi an meinem elero Rolladen-
Empfänger mal ausprobieren .. kann aber noch ein paar Tage dauern bis ich mehr weiss.

Habe keinen z-wave USB-Stick. :'(

Wünsch jedoch viel Erfolg beim Testen. ;)

Gruß Billy

Hi Leute,

also wenn das einer von euch zum Laufen bekommt wäre das für mich ein Grund mit mal ein Raspberry PI zuzulegen. Also bitte immer schön fließig weiter testen :-)

Das Centero ist mir einfach zu teuer für das was es kann.

Gruß
tobias

Hallo, gibt es schon Neuigkeiten zu diesem Thema. Wir haben die gleichen Rollos und ich würde die Dinger auch gerne über meinen Raspberry steuern. Schön wäre natürlich, wenn es hierzu eine einfache Lösung geben würde, da ich nicht so der begnadete Bastler bin.

Hallo zusammen,

mich würde das Thema auch brennend interessieren. Wir haben ein Haus gekauft und ich würde gerne die Rollos elektrisch betreiben und über fhem steuern.
Ist die einzige Lösung keine Elero-Motoren (mit Funk) zu nehmen und dafür andere Aktoren (z.B. von Homeatic) zu nutzen? Würde gerne meine Hilfe anbieten. Auch wenn ich kein E-Techniker bin habe ich genug Biss so lange an einem Problem zu hängen, bis es gelöst ist (passiert bei mumbi-Steckdosen mit Lernfunktion...).

Gruß

    Bjötn

Als Erstes würde ich versuchen einen Oszi mit 2 GHz Bandbreite auszuleihen. Einmal an den Antennenausgang anklemmen und gucken was da so passiert.

Je nachdem, was dabei rauskommt, kann man dann einen der billig verfügbaren Radiochips (CC1101, RF12) entsprechend programmieren.

Oder: Kann man erkennen, was da verbaut ist? Wenn ja: Digitales Mehrkanalteil dranhängen (mit USB-Schnittstelle nicht wirklich teuer), zugucken wie der Chip programmiert wird, Datenblatt runterladen, Chip kaufen, nachspielen.

Hi smurfix,

macht Sinn, und über die Hochschule käme ich sicherlich an die Hardware ran... aber ehrlich gesagt haben mich diese bescheurten lernenden mumbi-Steckdosen genug Nerven (und Zeit) gekostet. Werde auf Anraten aus dem Forum auf HomeMatic (LAN Adapter) in Verbindung mit fhem switchen. Ist wohl die beste Lösung...

Gruß

   Björn

Hallo,

vielleicht macht es ja Sinn das Thema elero zusammenzufassen.
Neben diesm thread wurde ja auch in den u.a. Links darüber diskutiert!

http://forum.fhem.de/index.php/topic,36041.msg289943.html#msg289943
http://forum.fhem.de/index.php/topic,34571.msg282222.html#msg282222

von elero gibt es ja wie dort schon erwähnt das EVA-Kit für Entwickler!
ich zitiere aus dem Schreiben der Entwicklerfirma an Fa. Elero.

ZitatHallo Herr ......,

wir haben(hatten) entschieden, dass wir den "kleinen" Befehlssatz für den Transmitter-Stick an Entwickler ohne Support rausgeben.
Das Packet heißt ,,Eva-Kit für Entwickler" und ist dieser E-Mail angehängt.

Damit ist es möglich den Transmitter-Stick von einem PC-Programm aus zu bedienen.
Das im Kit enthaltene Programm Sombrero kann zur manuellen Bedienung und als Hilfsmittel für die eigene Programmerstellung verwendet werden.

Zusammenfassend gesagt, ist dieses Eva-Kit nur für Softwareentwickler geeignet, die in der Lage sind, ohne Support, mit den enthaltenden Informationen ein Programm zur Bedienung des Transmitter-Sticks zu schreiben.

Das Kit besteht aus!
1. NTPort Library Driver 2.8 --> http://ntport-library-driver.software.informer.com/2.8/
2. Sombrero.exe  + Easy Control Transmitter Stick.pdf (ZIP in Anlage)
3. Centero_kurzBA_182030001_DE+EN+FR+IT+ES.pdf --> im Netz zum download

Vielleicht hilft das.

Ich würde mir so einen Stick anschaffen muss aber noch klären ob der auch für unidirektionale Verbindungen einsetzbar ist.

Gruß Billy

Hallo,

meine Nachforschungen haben ergeben, dass der Elero-USB-Stick nur mit den neueren bidirektionalen Rollladenmotoren funktioniert. Die älteren unidirektionalen Motore können nicht gesteuert werden. Hat man eine gemischte Installation dann werden die bidirektionalen Motore von Elero-Steuerungen als unidirektional angesteuert. (So ist es bei mir - 9 alte und 3 neuere Motore, die neueren weil die Elektronik in den Funkmotoren nach ein paar Jahren defekt war - Qualitätsprobleme bei Elero).

Wie im PDF des Development-Kits zu lesen ist, gibt es eine "Info Received". Das sin die Statusmeldungen, die der Stick vom Rollladenmotor erwartet. Der Stick will wissen, ob der Befehl erfolgreich ausgeführt wurde bzw. wenn nicht wie das Ergebnis ist (Fehlercode).

Bei unidirektionaler Steuerung werden die Befehle "blind" gesendet und es interessiert die Fernbedienung nicht ob die Aktion erfolgreich war.

Den USB-Stick anzusteuern sollte nicht so dramatisch sein. (Ich habe z.B. den Husqvarna AutoMower Rasenmäher-Roboter mit einem eigenen FHEM-Kommunikationsmodul und ZigBee Funkmodulen zum Laufen gebracht - nichts ist unmöglich.) Aber wenn der Stick nur mit bidirektionalen Empfängern zusammen arbeitet und andernfalls einfach blockiert dann sieht's nicht gut aus. Alle älteren Motore austauschen ist für mich zumindest keine Option (Kosten, Arbeitsaufwand).

Gruß, Klaus

Hallo zusammen,

gibt es inzwischen jemanden, der es geschafft hat den Elero Transmitter Stick anzusteuern?

Bei meiner Recherche stieß mir ein Thread ins Auge, bei dem der Stick auf einem HomeMatic System zum Laufen gebracht wurde: http://homematic-forum.de/forum/viewtopic.php?f=37&t=26066

Ich habe mittlerweile so einen Stick und versuche eine Integration des Sticks in FHEM. Eine Verbindung zum Stick habe ich hinbekommen.

Als ersten Schritt möchte ich den Easy_Check Befehl senden und die Easy_Confirm Antwort auswerten. (siehe angehängtes PDF)

Meine Konfiguration sieht aktuell so aus:

my $stick_serport = new Device::SerialPort ($dev);
$stick_serport->reset_error();
    $stick_serport->baudrate(38400);
    $stick_serport->databits(8);
    $stick_serport->parity('none');
    $stick_serport->stopbits(1);
    $stick_serport->handshake('none');
    $stick_serport->write_settings;
    sleep(1);
    $stick_serport->close(); 


Wie bekomme ich die Nachricht 0xAA 0x22 0x4A 0x0A gesendet?

Zitat von: Technikfreak am 27 August 2015, 17:28:22
Wie bekomme ich die Nachricht 0xAA 0x22 0x4A 0x0A gesendet?

Indem du dich in Perl-Programmierung einliest, insbes.
perldoc Device::SerialPort

Hallo zusammen,

für alle, die es interessiert. Mit Hilfe des DevIo Moduls ist es kein Problem die bidirektionalen Proline 2 Rolladenantriebe zum Laufen zu bekommen. Wichtig ist nur beim Devicenamen /ttyUSB0 die Baudrate @38400 anzuhängen. Anschließend kann man die Befehle wie im Eva-Kit beschrieben ausführen. Ich kann damit meine Rolläden nun steuern.

Hallo Technikfreak

Könntest du zu meinem besseren Verständnis mal bitte deine fhem.cfg Einträge posten?

Herzlichen Dank
Richi

Hallo,

also ich habe 2 Module geschrieben. Hierbei möchte ich betonen, dass es sich bisher lediglich um Prototypen handelt. Es ist nicht ausgereift und der Code ist auch nicht schön. Es funktioniert jedoch.

99_EleroStickUtils.pm
Dieses Modul repräsentiert den Elero Transmitter Stick und implementiert das im Eva Kit vorgegebene Protokoll. Es stehen folgende Sets und Gets zur Verfügung:
- set moveDown <Channel>
- set moveUp <Channel>
- set stop <Channel>
- set moveTilt <Channel> (diese Position muss zuvor am Rolladenmotor mit Hilfe des Sticks angelernt werden, siehe Elero Benutzerhandbuch)
- set moveIntermediate <Channel> (diese Position muss zuvor am Rolladenmotor mit Hilfe des Sticks angelernt werden, siehe Elero Benutzerhandbuch)
- get info (macht aktuell nichts)
- get check <Channel>

99_EleroDeviceUtils.pm
Repräsentiert die einzelnen Rolladenantriebe. Meine Überlegungen sind aktuell: Jeder belegte Kanal entspricht einem Device
Die oben genannten Gets und Sets funktionieren hier auch. Den Channel muss man hier nicht mitgeben, da das Device weiß, welchen Channel es hat. Die Devices werden aktuell nicht automatisch erstellt.

Meine Konfiguration sieht folgendermaßen aus:

define EleroStick EleroStickUtils /dev/ttyUSB0@38400
attr EleroStick icon cul_868
attr EleroStick room Rolläden

define EleroDevice1 EleroDeviceUtils EleroStick 1 10
attr EleroDevice1 IODev EleroStick
attr EleroDevice1 cmdIcon moveDown:fts_shutter_down moveUp:fts_shutter_up stop:fts_shutter_manual
attr EleroDevice1 devStateIcon top_position:fts_shutter_20 bottom_position:fts_shutter_90 moving_down:fts_shutter_down moving_up:fts_shutter_up
attr EleroDevice1 icon fts_shutter_40
attr EleroDevice1 room Rolläden
attr EleroDevice1 webCmd moveDown:stop:moveUp

define EleroDevice2 EleroDeviceUtils EleroStick 2 10
attr EleroDevice2 IODev EleroStick
attr EleroDevice2 cmdIcon moveDown:fts_shutter_down moveUp:fts_shutter_up stop:fts_shutter_manual
attr EleroDevice2 devStateIcon top_position:fts_shutter_20 bottom_position:fts_shutter_90 moving_down:fts_shutter_down moving_up:fts_shutter_up
attr EleroDevice2 icon fts_shutter_40
attr EleroDevice2 room Rolläden
attr EleroDevice2 webCmd moveDown:stop:moveUp


Die Module findet ihr im Anhang.

@Technikfreak
Herzlichen Dank, werd umgehend den Stick bestellen und mich ans testen machen!

Beim Einlernen des Sticks an die Antriebe gibt es übrigens einen Stolperstein. Wenn der Antrieb bereits angelernte Schalter hat, z.B. den Funkschalter UniTec 868, wie bei mir der Fall, muss dieser Schalter erst wieder "abgelernt" werden. Ansonsten hat bei mir das Einlernen mit dem Transmitter Stick nicht funktioniert. Danach ist das Anlernen des Funkschalters als zusätzlicher Schalter, wie in der Anleitung des Schalters beschrieben, möglich.

Hallo Technikfreak,

super!!, jetzt die Frage: ist es möglich mit dem Stick unidirektionale Antriebe (also welche keine Rückmeldung senden) zu betrieben??

Gerhard

Hallo Gerhard,

nein. Laut Elero funktioniert der Transmitter Stick nur mit den "neuen" Antrieben, die bidirektional kommunizieren können.

Moin Ihr Bastler und Experten,

bin frisch im Forum angekommen und bin seit 2 Tagen Newbee in Sachen Raspberry Pi 2 & Fhem. Ich habe verschwindend geringe (um ehrlich zu sein keine) Ahnung von Linux & Pearl, habe aber zwischenzeitlich Fhem auf dem Pi soweit am start, dass ich meine 433MHz Funksteckdosen schalten kann. Die besten Tipps an Newbees ("RTFM" & Pearl lernen) versuche ich zu beherzigen, aber mein technische Verständnis Programmierverständnis hat seine Grenzen und die zur fehlende Zeit im Alltag macht mir beim lernen leider einen Strich durch die Rechnung. Von daher bereits jetzt ein "mea culpa" für vielleicht all zu blöde Fragen :-)

In meinem Haus lasse ich demnächst die Terassentüren inkl. Rolläden austauschen -> neue Elero 868MHz bidi Funkmotoren (3 Stück) nebst einem Elero Tempotel 2 Handsender werden wohl zum Einsatz kommen, parallel möchte ich gerne per FHEM die Rolladensteuerung übernehmen. Es gibt keine Altlasten im Sinne von Unidirektionalen Motoren ...

Hatte ich diesen Thread soweit richtig verstanden, dass (hui, hoffentlich vergesse ich nichts) ich




• mir den Elero USB Stick kaufen muss (... wie heist das Teil genau und wo kann ich es erwerben?)
• gem. Posting http://forum.fhem.de/index.php/topic,15144.msg328654.html#msg328654 von TECHNIKFREAK die Dateien 99_EleroStickUtils.pm und 99_EleroDeviceUtils.pm in FHEM anlege
• die FHEM Config ergänze (auch gem. Posting von TECHNIKFREAK)
• und beim Anlernen des USB-Sticks nur dann funktioniert, wenn noch kein anderer Sender angelernt wurde (meinen Elero Tempotel 2 müsste ich dann im Anschluss anlernen?)

Hibt es eine Anleitung zum "Anlernen" des Sticks?

Funktionen wie "Sonnenstandsabhängige Schaltungen" benötige ich nicht, ich möchte lediglich mittels FHEM parallel zu dem Handsender die Rolladen runter bzw. Hochfahren können (letzteres ist insbesondere interessant, wenn man im Garten sitzt und die Rolladen mit Einbruchsschutz automatisch nach unten fahren und man sich ungewollt ausschließt :-))

Vielen Dank für Eure Mithilfe bzw. das "Nicht-Zerreißen" meiner Anfrage...

Gruß
MAiTRE

Hallo MAiTRE,

der Stick heißt Elero Transmitter Stick (http://www.smarthome-hannover.de/smart-home-online-shop-andere-anbieter/smart-home-online-shop-elero-produkte/elero-centero-haussteuerung/ (http://www.smarthome-hannover.de/smart-home-online-shop-andere-anbieter/smart-home-online-shop-elero-produkte/elero-centero-haussteuerung/)). Die Anleitung zum Anlernen ist dem Stick beigelegt. Ob du deine Fernbedienung vorher oder nachher einlernen musst weiß ich nicht. Wenn die Fernbedienung bidi läuft, könnte es auch andersrum gehen.

Hallo an alle FHEM Fans,
@ Technikfreak ein besonders Lob. Seit Monaten hoffe ich auf den Durchbruch bei ELERO. Super Arbeit. Jetzt gehts in die Feinheiten. Die Namensgebung ist noch fix eingestellt. Hängt vermutlich mit dem Konzept der logischen bzw physikalischen Device zusammen. Ich habe beide Routinen umgestellt, so dass die Namen beliebig geändert werden können. Ich möchte Technikfreak die Butter nicht vom Brot nehmen. @Technikfreak: Bitte e-mail an mich und ich sende die Routinen.

Grüße
mabula

Hallo,
ich habe 2 Rolläden mit einer Elero Steuerung (Combio-868) und einer Fernbedienung von Elero (VarioTel Plus).
Kann ich diese mit den deiden Elero Modulen 99_EleroDeviceUtils.pm oder 99_EleroStickUtils.pm ansteuern.
Zur Ansteuerung hätte ich einen Cul zur Verfügung.

Vielen Dank für die Unterstützung
Mario

@Technikfreak: Super, vielen Dank, meine 12 Stück ProLine 2 Antriebe warten schon lange drauf, sich mit FHEM anzufreunden.

Ich konnnte den Elero Transmitter Stick problemlos auf meine ProLine-2 Antriebe einlernen, obwohl auf jedem bereits ein UniTec-868 und ein TempoTel 2 eingelernt waren.
Ich musste meine UniTec-868 vorher nicht ablernen.

Am UnitTec die Tasten Prog, Up und Down geleichzeitig für drei Sekunden drücken, um den Antrieb in den Lernmodus zu bringen
Am Transmitter Stick die Taste "P" für drei Sekunden drücken
Dann das Auffahrt-Abfahrt Reaktionsspiel bestehen
Und schon kann der Transmitter Stick (die UniTec natürlich auch noch) den Rollanden fahren lassen.

Die 99_EleroStickUtils.pm und 99_EleroDeviceUtils.pm in FHEM gepackt und die devices angelegt.
Damit funktioniert die Steuerung der Rolläden generell schon mal. Sehr schön!

Mir ist klar, dass die Module ein Prototyp (der schon sehr gut funktioniert) sind, darum bitte meine Punkte nicht als Kritik verstehen.

Einige Fragen und Punkte dazu:
- Hast Du geplant, das Modul offiziell in FHEM zur Verfügung zu stellen (also im trunk eingecheckt)?
  Meiner Meinung nach ist es so wertvoll, dass es da hingehört und nicht in einem Thread oder contrib versinken sollte.

- Ich musste erst mal mit cpan das Switch-Modul nachinstallieren, das wird von keinem Modul, das ich bisher in FHEM benutze, benötigt.
  Evtl. sollte man versuchen ohne Switch klarzukommen. Ich hatte das auch, mal ganz kurz nur :-) im LaCrosse Modul drin und habe es zurückgerudert,
  weil viele Anwender das Switch nicht installiert hatten.

- Statische device names ('EleroDevice' prefix) wie schon von mabula erwähnt

- Es wäre zu überlegen, ob man anstatt in EleroDeviceUtils in EleroStickUtils einen Timer laufen lässt, der die Stati ermittelt und die
  EleroDeviceUtils aktualisiert, sonst laufen da (bei mir) 12 Timer, die "get info" Anfragen an EleroStickUtils stellen, das
  wiederum auf dem HF-Weg den Antrieb fragt. Somit hat man permanent Trafic auf der HF-Strecke.
  So wäre es nur alle <interval> Sekunden ein mal gebündelt.
 
- Da man die ProLine 2 Antriebe leider nicht auf eine beliebige Position (außer auf, zu und die programmierte Zwischenposition) fahren kann,
  könnte man ein Atribut machen, in dem man die Laufzeit von auf bis zu des jeweiligen Antriebs definiert. Damit könnte man dann den Rolladen
  auf z.B. "60% auf" oder jede bel. andere Position fahren, indem man gem. der Gesamtlaufzeit die erforderliche Fahrzeit berechnet.

- Weitere Ideen werden sich nicht vermeiden lassen :-) 

- Ich werde mal noch schauen, welche readings usw. sinnvoll wären, um es relativ einfach über fronthem in SmartVisu anzubinden (device.shutter)


Auf alle Fälle ist das eine echt coole Sache!

Nachtrag:

Zitat von: MarioS1969 am 10 September 2015, 19:28:06Zur Ansteuerung hätte ich einen Cul zur Verfügung.

Das wird nicht gehen, dazu ist der "Elero Transmitter Stick" erforderlich.

Hallo an Alle,

da doch Bedarf für Routinen mit beliebiger Namensgebung und ohne die Library Switch besteht, stelle ich meine Änderungen der Routinen von Technikfreak ins Forum. Kredit für Technikfreak steht in der Kopfzeile.
Einträge in der Config sind wie folgt:
"define EleroStick_1 EleroStick /dev/ttyUSB0@38400,8,N,1"
für den Stick selbst und
"define Rollo_WZ_r EleroDevice EleroStick_1 1 300"
"attr Rollo_WZ_r IODev EleroStick_1"
für die Rollladen. Die Update Rate von 300 sollte die Funkbelastung reduzieren. Halt etwas geduld bis der Status aktuell ist!

Gruß

Hallo zusammen,

es freut mich, dass euch mein kleiner Prototyp weiterhilft. Aktuell habe ich aus Zeitgünden nicht geplant, ein offizielles Modul daraus zu machen. Den Prototyp zu bauen war nur eine Notlösung, weil es mich sehr genervt hat, dass es für die Antriebe noch nichts gibt ;-) Mein Ziel war daher, den Stein, die Rolläden endlich steuerbar zu machen, ins Rollen zu bringen. Dementsprechend finde ich es gut, wenn ihr noch die ein oder andere Verbesserung einbaut und gerne auch eincheckt und supported. Werde die neue Version gleich einmal ausprobieren.

Gruß

@Technikfreak: OK, dann rollen wir den Stein weiter. Ich würde das Modul als maintainer übernehmen und offiziell machen, es sei denn, mabula möchte gerne developer Status beantragen und es übernehmen, dann lasse ich ihm gerne den Vortritt (oder jedem anderen, der möchte). Eigentlich fehlt mir auch ein wenig die Zeit, aber wie schon geschrieben, ich hätte es gerne in FHEM drin.

Hallo,

nein ich habe nichts dagegen, wenn HCS das Modul eincheckt. Ich habe noch einen Versuch laufen, die im physischen Modul gelesen Daten mit Parse im logischen Modul zu übernehmen. Leider bin ich noch nicht in alle Geheimnisse vorgedrungen und es läuft noch nicht wie ich mir das vorgestellt habe. Vielleicht habe ich das Modul Parse auch falsch verstanden. Mit wem könnte ich meine Experimente austauschen? Danach müsste dann Autocreate realisiert werden.
Gruß

Hi mabula,

über das "Dispatch->Parse" Thema habe ich auch gerade nachgedacht. Gut dass ich noch nichts gemacht habe, wenn Du schon dran bist.
Es wäre sehr sinnvoll, das darüber zu machen, dann wäre das nämlich "FHEM2FHEM raw" fähig und mit clients/matchlist auch erweiterbar.
Ein Beispiel dafür ist z.B. 36_JeeLink -> 36_LaCrosse / 36_Level / 36_EMT7110

Siehe auch hier: http://www.fhemwiki.de/wiki/DevelopmentModuleIntro#Zweistufiges_Modell_f.C3.BCr_Module

Wenn wir es arangiert bekommen, können wir uns auch gerne irgend welche Arbeit aufteilen.
Kannst es mir schicken, wenn ich mal drauf schauen soll.

HI HCS,

Leider, leider muss ich noch ab und zu arbeiten. ich komme erst Mitte nächster Woche wieder dazu an diesem Thema weiterzuarbeiten. Ich werde mir die Empfehlungen anschauen.

Viele Grüsse

Zitat von: mabula am 15 September 2015, 18:01:53
Leider, leider muss ich noch ab und zu arbeiten.

Oh, ein Leidensgenosse  ;D

Ich habe es dann doch mal auf Clients/MatchList, Dispatch() -> Parse() und IOWrite() umgebaut.
Dann lass mich mal ein Stück weiter machen und wir schauen Mitte nächster Woche wie es weiter geht.
Habe es auch von 99_ auf 36_ geschoben, da 99_ Module automatisch geladen werden, auch wenn es keine defines dafür gibt.

Hallo zusammen,

ich habe in der Weinor Doku zur BiEasy-Box (Link unten) folgendes gelesen: "...Netzwerkkabel zur Verbindung des Centero Server mit einem Heimnetzwerk...".
Weiss jemand, ob das BiEasy-Funksystem von Weinor das hier im Thread beschriebene Centero ist? Der Server (die Box) und der USB-Stick sehen identisch aus und das obige Zitat aus der Weinor-Anleitung deutet auch darauf hin.
Dann wäre das vielleicht der Durchbruch für alle Weinor-Besitzer mit BiConnect Funksystem (868 Mhz).

Hier der Link zur Weinor-Anleitung:
http://www.weinor.com/app-support-de/117443_Haupt-Bedienungsanleitung_BiEasy_Set_D_15112013.pdf (http://www.weinor.com/app-support-de/117443_Haupt-Bedienungsanleitung_BiEasy_Set_D_15112013.pdf)

Noch ein Update: Auf den Seiten von der Elero GmbH sind die Fernbedienungen abgebildet. Diese entsprechen exakt den Weinor Pendants.
Link: https://www.elero.de/de/produkte/steuerungen-fuer-rohrantriebe/

Ein Modul für Weinor wäre der Hammer, da wird hier im Forum ja häufig nach gefragt.

Danke für Eure Infos und viele Grüße,
Dirk

Zumindest steht hier (http://www.mysonnenschutz.de/content/Prospekt%20Funkkomfort.pdf) auf Seite 3: "Zudem ist das WeiTronic System kompatibel zum Elero-Funksystem und dadurch breit einsetzbar"

Die Wahrscheinlichkeit, dass das geht, ist also sehr hoch.
Um es definitiv zu wissen, müsste sich jemand opfern und einen Elero Transmitter Stick beschaffen und schauen, ob er den auf eine Weinor Markise eingelernt bekommt.

Das kann man erst mal noch ohne FHEM testen, ich kann mit dem Elero Transmitter Stick pur an einem 5V USB-Netzteil meine Elero Rollläden mit den Up, Stop und Down Tasten am Transmitter Stick fahren (nachdem ich den Stick auf die Antriebe eingelernt hatte)

Weinor bietet den Stick auch an, mal sehen, wo man den günstiger bekommt  ;)
Die Weinor-Komponenten werden bis Ende Oktober installiert, danach könnte ich testen.

Noch eine Frage, kann man einen solchen USB-Stick auch abseits des FHEM-Servers einbinden?
Hintergrund: Mein FHEM läuft auf einer Syno im Keller. Kann man den Stick auch z.B. an einem Router einstecken und per FHEM darauf zugreifen?

Zitat von: Dirk070 am 16 September 2015, 12:23:37Noch eine Frage, kann man einen solchen USB-Stick auch abseits des FHEM-Servers einbinden?
Hintergrund: Mein FHEM läuft auf einer Syno im Keller. Kann man den Stick auch z.B. an einem Router einstecken und per FHEM darauf zugreifen

Wenn Du den USB-Port mit einem usb-redirector auf dem FHEM-Rechner verfügbar machen kannst, dann evtl. ja, da gibt es verschiedene Lösungen dafür (aber frag mich nicht nach Details).

Nach dem Umbau, den ich gerade mache, sollte zumindest FHEM2FHEM gehen.

Aber, hat denn die DiskStation keine USP-Ports?

Doch, doch, die Syno hat einen USB-Port.

Aber die Syno steht im Keller, damit auch der Stick (der sendet) und die Markise ist auf der Terrasse.
Problem: Eventuell schafft der Sender es nicht zum Empfänger  ::)

Daher die Überlegung, den Sendestick näher an die Terrasse zu bringen.

Zitat von: Dirk070 am 18 September 2015, 17:56:27Daher die Überlegung, den Sendestick näher an die Terrasse zu bringen.

Ja, macht wohl nur so rum Sinn  ;D ;D

Ich würde mal abwarten, ob die Reichweite passt. Bei den Rollladenantrieben ist es so, dass die die Telegramme weiterleiten, was die Reichweite erhöht.
Und generell sind die 868 MHz Komponenten nicht schlecht von der Reichweite. Ich funke damit quer durchs Haus, von Keller bis ins DG. Allerdings ohne viel Stahl in den Wänden und Decken.

Eine Beta zum Testen (erst mal entspannt zurücklehnen und den folgenden Roman in Ruhe lesen ;D) :

Die Module sind nun 36_EleroStick und 36_EleroDrive.

Da der Stick auch Elero Schaltaktoren (z.B. Unio-868) beherscht, kann es dann evtl. parallel zu 36_EleroDrive weitere Module geben, z.B. 36_EleroSwitch.

Auf Dispatch -> Parse / IOWrite umgebaut, somit ist FHEM2FHEM RAW möglich.

Autocreate ist implementiert. Es wird bei Autocreate bewusst kein FileLog angelegt, nur das EleroDrive Device.

Die commandref habe ich auch schon weitestgehend für die beiden Module.

EleroStick ermittelt nun perisodisch den Zustand aller auf dem Stick eingelernten Antriebe und verteilt es per Dispatch auf die EleroDrives.
Dazu kann man zwei Attribute setzen:
ChannelTimeout: Sekunden, wie lange auf eine Antwort eines Kanals gewartet wird, bevor der nächste Kanal abgefragt wird.
Default = 5 Sekunden, kann ich bis auf 2 Sekunden runternehmen. Wenn man den Wert kleiner als die Antwortzeit des langsamsten Antriebs (nicht die Laufzeit, sondern die Zeit, bis er auf eine "Frage" antwortet) wählt, verpasst man dessen Antwort.
Interval: Sekunden, wie lange gewartet wird, bis die Kanäle, nachdem sie abgefragt wurden, erneut abgefragt werden. Default = 60 Sekunden.

Der Ablauf ist folgendermaßen: Bei der Initialisierung oder nach dem Anstecken des Stick an den Server werden die eingelernten Kanäle ermittelt.
Die sieht man dann im internal "channels". Beispiel: "111111111100000" hier sind Kanal 1 bis 10 am Stick eingelernt.
Es werden nacheinander alle eingelernten Kanäle abgefragt. Wärend dessen zeigt das internal "channels" den aktuellen Kanal als "x".
Beispiel: "111x11111100000", bedeutet, dass aktuell Kanal 4 abgefragt wird. Das x wandert also von links nach rechts durch die eingelernten Kanäle.
Die eingelernten Kanäle dürfen auch Lücken aufweisen, was dann z.B. so aussieht: "011001100000000" = eingelernt sind Kanal 2,3,6 und 7
Wenn alle Kanäle abgearbeitet sind, wird "interval" Sekunden gewartet, bis die Kanäle erneut abgefragt werden.

Die readings AnswerMsg, AnswerType, SendMsg, SendType im EleroStick zeigen an, was an Kommunikation zwischen Stick und FHEM läuft und dienen eher zu Überwachung und Fehlersuche.

Die Definition für den EleroStick sieht nun so aus:

define myElero EleroStick /dev/ttyUSB1@38400
attr myElero ChannelTimeout 2
attr myElero Interval 60

Und ein Beispiel für EleroDrive (für den Kanal 2):
define EleroLivingRoomEast EleroDrive 2
attr EleroLivingRoomEast IODev myElero
attr EleroLivingRoomEast cmdIcon moveDown:fts_shutter_down moveUp:fts_shutter_up stop:fts_shutter_manual
attr EleroLivingRoomEast webCmd moveDown:stop:moveUp

Bei der Definition für ein EleroDrive muss man kein IO-Device mehr angeben, das kann es selbst ermitteln und der Timer ist auch entfallen, da ja nun die EleroDrive ihren Status nicht aktiv holen müssen sondern von EleroStick geschickt bekommen.


Der weitere Plan:
Testen
Evtl. nächste Woche offiziell in FHEM reinpacken
EleroStick muss noch lernen, sich mit seiner Abfrageschleife zurückzuhalten, wenn ein EleroDrive etwas sendet (da kann es noch zu Kollisionen kommen)
Ein Attribut in eleroDrive, mit dem man definiert, wie lange dieser Antrieb für eine komplette Fahrt benötigt.
Damit will ich zum einen den Status frühest möglich aktualisieren, nachdem man den Antrieb gefahren hat und auf eine beliebige Position fahren können, z.B 30% auf.
Ein Reading mit der aktuellen Position als numerischen Wert, mit dem man in Frontends wie z.B. SmartVisu einfacher arbeiten kann.

@Technikfreak: vielen Dank nochmal für Deine Vorarbeit, das war sehr hilfreich.

@All: Gefundene Fehler und Ideen sind willkomen.

Nachtrag: falls jemand Lust hat, das demnächst im Wiki zu dokumentieren und dort zu pflegen, darf er sich gerne melden  ;)

Grosses Lob an Euch alle!
Hab's so getestet wie von HCS vorgeschlagen, und es läuft perfekt. :)

Zitat von: chaot4ever am 22 September 2015, 10:45:49
Grosses Lob an Euch alle!
Hab's so getestet wie von HCS vorgeschlagen, und es läuft perfekt. :)

Sehr schön!

Hast Du die 36_EleroStick und 36_EleroDrive vom 20. September genommen?

ja, genau diese, habe auch die Heizungssteuerung von Elero dran angebunden, geht ebenfalls:
top_position ist aus, bottom_position ist ein, dimmstufen werden nicht zurückgemeldet.

Zitat von: chaot4ever am 22 September 2015, 16:21:27
ja, genau diese, habe auch die Heizungssteuerung von Elero dran angebunden, geht ebenfalls:
top_position ist aus, bottom_position ist ein, dimmstufen werden nicht zurückgemeldet.

Oh... dann hat ja schneller als ich dachte jemand so was im Einsatz.
Welche Typenbezeichnung hatt denn das Ding?
Dann würde sich wohl doch ein 36_EleroSwitch dafür anbieten. Können wir angehen, wenn die Antriebe mal produktiv rund sind.
top_position und bottom_position ist für Aus/Ein dann doch nicht so eingängig  :)

Falls nicht noch etwas gravierendes auftritt, mache ich bis Ende der Woche ernst und packe es in FHEM rein, dass es mit dem Update mitkommt.

Zitat von: chaot4ever am 22 September 2015, 16:21:27...dimmstufen werden nicht zurückgemeldet.

Wie bei den Antrieben. Echt schade, dass die Antriebe keine konkrete Position zurückmelden.

Die Bezeichnung ist: Combio 868 HE

Hallo HCS,

die neue Version läuft super. Noch zwei Anregungen/Fragen: Die Sticks haben nur 15 Kanäle, da ist die Wahrscheinlichkeit groß, dass mehrere parallel betrieben werden. Reicht dann die Kanalangabe für die Zuordnung?
Hilfreich für die nachträgliche Überprüfung der Funktion wäre ein Log-Eintrag des ausgeführten Kommandos (verbose 3).

Gruß

Zitat von: mabula am 23 September 2015, 20:50:01Die Sticks haben nur 15 Kanäle, da ist die Wahrscheinlichkeit groß, dass mehrere parallel betrieben werden. Reicht dann die Kanalangabe für die Zuordnung?

Das sollte gehen. Dann hat man ja zwei Transmitter-Sticks und dafür auch zwei 36_EleroStick defines. Für die Antriebe auf dem zweite Stick ändert man das IODev Attribut im 36_EleroDrive.

Zitat von: mabula am 23 September 2015, 20:50:01Hilfreich für die nachträgliche Überprüfung der Funktion wäre ein Log-Eintrag des ausgeführten Kommandos (verbose 3).

Verbose 3 finde ich etwas heftig. Aktuell ist aber gar kein Logging drin. Da muss ich eh noch überlegen, was wann geloggt werden sollte.

Ich habe die Module eingecheckt, die sollten dann ab morgen mit dem normalen FHEM-Update mitkommen.

Und einen neuen Thread dazu gibt es auch weil:
- Er dann da ist, wo er hingehört
- Ich den obersten Beitrag ändern können will
- Nicht erst nach drei Seiten das Wesentliche kommen sollte

hier geht es dann weiter: http://forum.fhem.de/index.php/topic,41466.msg337093.html#msg337093

Ich schlage vor, diesen Thread zu schließen.

Hallo,
ich habe 2 Rolläden mit einer Elero Steuerung (Combio-868) und einer Fernbedienung von Elero (VarioTel Plus).
Kann ich diese mit den beiden Elero Modulen 99_EleroDeviceUtils.pm oder 99_EleroStickUtils.pm ansteuern?
Oder wird noch der Elero-USB-Stick benötigt?

Zur Ansteuerung hätte ich einen Cul zur Verfügung.

Vielen Dank für die Unterstützung
Mario

Zitat von: MarioS1969 am 22 November 2015, 21:12:40
Oder wird noch der Elero-USB-Stick benötigt?

Ja, ohne den geht das nicht.
99_EleroDeviceUtils.pm und 99_EleroStickUtils.pm sind überholt.
Aber auch die neuen Module benötigen den Stick.
Mit einem CUL geht das definitiv nicht.

Du hast gesehen, dass es hier weiter geht? http://forum.fhem.de/index.php/topic,41466.msg337093.html#msg337093

Hallo,
schade, der Stick ist mit 140 Eur recht teuer. Ich muss mir dann ersteinmal überlegen, ob ich dann nicht auf HM umrüste.
Vielen Dank aber für die schnelle Antwort und die ELERO Module.

Hallo liebe Forumsmitglieder,

ich brauche bitte Euren Rat ob das folgende Setup per FHEM steuerbar ist:

Motoren: Elero RolTop 868-M10 und _m20
Fernsteuerung: Vario Tel 2

Würde dann natürlich noch den Elero Stick dazukaufen.

Kann man mit diesem Setup per FHEM die Rolladen bedienen ?

LG
Joachim

Hallo Joachim,

ja das funktioniert super.
Die RolTop 868 haben das ProLine 2 Protokoll.
Dieses lässt sich super mit dem Stick ansteuern. Welche Fernbedienung du hast ist egal. Ich habe zwei TempoTels.
Habe auch erst gezögert mit dem Stick aber ich bereuhe es nicht.
Viele Grüße

Hallo Vitolinker,

spitze , vielen Dank für Deine Antwort.

Dann kann ich das ja so einbauen lassen (freu) !

Viele Grüße
Joachim

Hallo zusammen,

hat jemand von euch zufällig schonmal versucht 2 EleroSticks anzubinden? Ich habe 2 im Einsatz und das Problem, dass sich der Status der Rolläden in FHEM ständig verändert, obwohl sie sich gar nicht bewegen. (auf, zu, undefined position, ...). Ich kann mir diesen Zustand nicht so recht erklären und habe es noch nicht geschafft ein Muster zu identifizieren, nach dem dies geschieht. Mit einem Stick war zuvor alles normal.

Zitat von: Technikfreak am 10 September 2017, 10:02:58
hat jemand von euch zufällig schonmal versucht 2 EleroSticks anzubinden?

Nein, habe nur einen. Ich kann aktuell auch wirklich nicht sagen, ob das funktionieren kann.
Ich glaube aber, dass das Problem ist, dass beide Elero-Stick devices jeweils die Kanäle 1 ... 15 dispatchen was dann bei den EleroDrives des jeweiligen Kanals dazu führt, dass sie abwechselnd Daten vom einen und anderen Stick erhalten. Das würde recht genau das beobachtete Verhalten erklären.

Ich denke, dass man (also ich) dem EleroStick device einen ChannelOffset spendieren müsste, dass der zweite Stick die Kanäle auf 16 ... 30 umsetzt.

Die Devices sind einem Stick zugeordnet. Dadurch weiß der Stick doch eigentlich welches Device aktualisiert werden muss. Ein Device ist durch die Kombination aus Zuordnung zu einem Stick + Kanal eindeutig definiert. Wenn das der Grund ist müsste im FHEM Core etwas fundamental falsch laufen. Da würde meiner Ansicht nach auch kein Offset etwas bringen.

Das Problem tritt nur beim Status auf. Die Steuerung funktioniert. Wenn ich Kanal 2 runterfahre fährt nur der Rolladen runter, der dem Stick zugeordnet ist. Der Rolladen am anderen Stick auf gleichem Kanal bewegt sich nicht. Deshalb scheint es kein grundsätzliches Problem mit doppelten Kanalnummern zu sein.

Zitat von: Technikfreak am 11 September 2017, 17:47:10
Ein Device ist durch die Kombination aus Zuordnung zu einem Stick + Kanal eindeutig definiert.

Wodurch ein device eindeutig definiert ist, entscheidet das device und bei EleroDrive ist es momentan einzig und allein der Kanal.

Zitat von: Technikfreak am 11 September 2017, 17:47:10
Wenn das der Grund ist müsste im FHEM Core etwas fundamental falsch laufen.

Da läuft nichts falsch. Es ist nicht Aufgabe des FHEM-Core, die richtige Instanz vom logische Modul zu finden, sondern Aufgabe vom logischen Modul.
Wenn die Parse des logischen Moduls (noch kein konkrete Instanz) die Daten vom physischen Modul bekommt, dann muss sie die richtige Instanz finden. An der Stelle könnte man natürlich noch das IODev berücksichtigen, da es zwei Instanzen mit dem Kanal gibt, von denen nur eine das richtige IODev hat. Falls das device aber noch nicht angelegt ist, muss autocreate es anlegen. Und das haut nicht hin, weil es bereits ein device mit dem Namen und Kanal gibt.

Zitat von: Technikfreak am 11 September 2017, 17:47:10
Das Problem tritt nur beim Status auf. Die Steuerung funktioniert. Wenn ich Kanal 2 runterfahre fährt nur der Rolladen runter, der dem Stick zugeordnet ist. Der Rolladen am anderen Stick auf gleichem Kanal bewegt sich nicht. Deshalb scheint es kein grundsätzliches Problem mit doppelten Kanalnummern zu sein.

Die Steuerung funktioniert, weil EleroDrive immer an das physische device sendet, das in IODev festgelegt ist.

Zitat von: Technikfreak am 11 September 2017, 17:47:10
Da würde meiner Ansicht nach auch kein Offset etwas bringen.

Stell Dir vor, ein Stick könnte Kanal 1 bis 30. Würde ohne Probleme funktionieren.
Jetzt teilen wir den Stick in der Mitte und die eine Hälfte liefert 1 bis 15 und die andere Hälfte 16 bis 30. Funktioniert immer noch.
Also bringen wir dem zweiten Stick bei, dass er die "16 bis 30 Hälfte" ist und nicht nochmal ein "1 bis 15".
Und um es ihm beizubringen setzen wir ihm (und nur ihm, dem ersten nicht) ein Attribut:
"attr mySecondStick firstChannel 16"

Wenn man auf autocreate für die Kanäle vom zweiten Stick verzichtet, dann bekommt man es wohl auch ohne eindeutige Kanäle hin.
Wäre auch eine Option, ist vermutlich weniger Aufwand. Könnte ich mal testweise implementieren.

Irgendwie erschien mir die "Kanal eindeutig" Variante eingängiger, aber es wäre dann auch noch einen Versuch wert, zu ermitteln, ob es schon eine Instanz mit dem Kanal und einem anderen IODev gibt und in diesem Fall es mit einem anderen Namen von autocreate anlegen zu lassen.

Okay das ergibt Sinn.
Wäre super, wenn du das bei Gelegenheit einbauen könntest. Danke schonmal!

Zitat von: Technikfreak am 12 September 2017, 07:03:46
Wäre super, wenn du das bei Gelegenheit einbauen könntest. Danke schonmal!

Anbei eine Version zum testen. Da ich nur einen Stick habe, kann ich es leider nur simulieren aber nicht in echt testen.

EleroDrive berücksichtigt nun auch das IODev, so dass mehrere EleroDrive mit dem gleichen Kanal funktionieren.
Autocreate legt nun devices mit diesem Namensschema an: EleroDrive_<IODev>_<Kanal>
Die Zuordnung des richtigen IODev beim Anlegen durch Autocreate funktioniert nun auch.

Ich habe es seit gestern bei mir mit einem Stick in der Produktivumgebnung laufen, mit einem Stick scheint alles wie gehabt zu laufen.

Wenn es bei Dir mit zwei Sticks wie gewünscht funktioniert, dann baue ich die Änderung auch in EleroSwitch ein und checke es dann offiziell ein.

Zitat von: HCS am 17 September 2017, 08:46:27
Anbei eine Version zum testen.

Da gibt es noch ein kleines Problem, habe sie wieder zurückgezogen.
Wenn ich es im Griff habe, hänge ich sie dann im nächsten Beitrag an.

Zitat von: HCS am 17 September 2017, 18:57:45
Wenn ich es im Griff habe, hänge ich sie dann im nächsten Beitrag an.

So jetzt aber.
Probier das mal bitte, ob das bei Dir klappt.

Hallo,

sieht so aus als funktioniert es. Kann das Problem seit dem Update nicht mehr erkennen. Vielen Dank!

Prima, ich warte mal noch ein wenig, ob Du doch noch Probleme entdeckst, wenn nicht, checke ich es dann ein.

Hi,

Mein deutsch ist nicht perfekt.
Ich habe ELERO protocol reverse engineered.
Momentan ohne dokumentation aber gibts verschiedene beispiele und PYTHON code wie man "encrypt" könnte.

https://github.com/QuadCorei8085/elero_protocol

Ihr könnte auch beischpiele für ESP32 finden.

Zitat von: Michi
ich bin zufällig über einen Post im Forum gestolpert (https://forum.fhem.de/index.php/topic,15144.75.html Post #79 ) welcher mich an ein altes Elero Problem erinnert hat. Ich würde nämlich gerne die Nachrichten der Windsensoren mitlesen können, um dann in Fhem die Aktion der Rolläden zu steuern (anstatt Sensor und Aktor direkt zu koppeln - ist auf dem Dach nämlich gar nicht so einfach). Der gerne verwendete Elero USB Transmitter Stick kann das nämlich genau nicht (wie auch andere spannende Dinge).

Wäre das nicht etwas für den Signalduino 868 MHz (zumindets für HW mit C1100)?

Die SPI Config Register stehen in https://github.com/QuadCorei8085/elero_protocol/blob/main/main.cpp#L532
Demnach ist die Frequenz 869,525MHz mit GFSK Codierung wenn ich das richtig dekodiert habe. Das ist zwar etwas "neben" dem 868,3MHz Standard aber wohl für die Abtsimmung immer noch nah genug.

Hier ist ein erster Versuch, bitte mal testen ob mit meiner Firmware (3.3.4 oder 4.x.x) was empfangen wird
https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900

get sduino raw CW0007,0209,0307,04D3,0591,063C,078C,0845,0B08,0D21,0E71,0F7A,107B,1183,1213,1352,14F8,1543,173F,1818,191D,1A1C,1BC7,1C00,1DB2,21B6,2211,23EA,242A,2500,261F,3D0D,3E04,4045,416C,4272,436F,4400
Dies ergibt die folgenden Werte:
freq:869.525MHz bWidth:232KHz rAmpl:42dB sens:12dB (DataRate:76766.97Baud)

N=13 ccmode=4 sync=D391 Modulation:GFSK (SYNC_MODE:30/32 sync) DEVIATN:34.912kHz

Gruß Ralf

Hallo Ralf, hallo quadcorei8085,

Vielen Dank für Eure Unterstützung und schnelle Hilfe bzw. Umsetzung.

Ein weiterer Signalduino zum Testen ist bestellt. Ich werde berichten...

Viele Grüße

Michi

Bisher hatte ich leider kein Glück etwas zu empfangen

   
• Mein Arduino Nano weigert sich hartnäckig die neue Firmware zu flashen. Daher bin ich auf einen Busware CUL_3 868MHz ausgewichen
• Verwendete Firmware ist die SIGNALduino_culV3CC1101_onlyFsk_334dev211207.hex
• Kannst du mir bei dem raw Kommando noch mal auf die Sprünge helfen?
• 
        
  • Wenn erfolgreich – bekomme ich dann nur eine empfangene Nachricht angezeigt oder kontinuierlich?
  • Ich hatte mir die SPI Register noch einmal angeschaut. In dem Kommando sind sie etwas anders als in dem Beispiel von quadcorei8085. Ist das gewollt?
  • Die Zugriffe auf die Register 40xx am Ende des Raw Kommandos habe ich nicht verstanden. Ist das ein Burst Zugriff? Oder ist das etwas anderes?

Viele Grüße, Michi

ZitatMein Arduino Nano weigert sich hartnäckig die neue Firmware zu flashen.

Hast Du es auch mit "attr sduino hardware nanoCC1101_optiboot" versucht, falls der nano einen optiboot Bootloader hat.

Die Nachrichten sollten kontinuierlich kommen.

Zitat
Die Zugriffe auf die Register 40xx am Ende des Raw Kommandos habe ich nicht verstanden.

3D0D ist ccN = 13
3E04 ist ccmode = 4
40 - 47 ist die max 8 Zeichen Bankkurzbeschreibung ( hier ist 4045,416C,4272,436F,4400 Elro)

ZitatIch hatte mir die SPI Register noch einmal angeschaut. In dem Kommando sind sie etwas anders als in dem Beispiel von quadcorei8085. Ist das gewollt?

Wo hast Du außer bei außer beim reg 00 (07 anstatt 06) abweichungen festgestellt?

Die Testregister "2959,2C81,2D35,2E09" sind nicht im Raw Kommando enthalten, Du kannst sie mal Testweise mit "set sduino cc1101_reg" setzen.
Die Testregister gehen bei einem Bankwechsel oder einem reset verloren, da sie nicht im EEPROM gespeichert werden.

Du kannst auch mal testen ob es was bringt, wenn Du die reg 00, 07 und 08 änderst.

00 GDO2 von alt 07 nach neu 01
GDO2 1
Associated to the RX FIFO: Asserts when RX FIFO is filled at or above the RX FIFO threshold or the end of packet is
reached. De-asserts when the RX FIFO is empty.
GDO2 7
Asserts when a packet has been received with CRC OK. De-asserts when the first byte is read from the RX FIFO.

07 PKTCTRL1 von alt 8C nach neu 84
Bit 3:  Enable automatic flush of RX FIFO when CRC is not OK. This requires that
only one packet is in the RXIFIFO and that packet length is limited to the
RX FIFO size.

08 PKTCTRL0 von 45 nach 44
Bit 0 + 1
00 Fixed packet length mode. Length configuredPKTLEN register
01  Variable packet length mode. Packet length configured by the first byte after sync word

Gruß Ralf

Die gute Neuigkeit gleich am Anfang. Ich kann Nachrichten empfangen! Vielen Dank für die Hilfe.

Ich habe einiges ausprobiert, aber am Ende macht der Wert im C1101 Register 0x3E den Unterschied. Verwendet habe ich:

CW0007,0209,0307,04D3,0591,063C,078C,0845,0B08,0D21,0E71,0F7A,107B,1183,1213,1352,14F8,1543,173F,1818,191D,1A1C,1BC7,1C00,1DB2,21B6,2210,23EA,242A,2500,261F,2C81,2D35,2E09,3D0D,3EC2,4045,416C,4265,4372,446F,4500

Empfangen wird zum Beispiel:
2022-04-15 13:16:06 SIGNALduino sduino_868 RAWMSG MN;D=1BE74510050101F58D2AF58D2AF58D2A01110042CD317F734D01C705FFB1;N=13;R=220;
2022-04-15 13:16:06 SIGNALduino sduino_868 RAWMSG MN;D=1BE74510150101F58D2AD91023F58D2A01110042CD317F734D01C705F9AF;N=13;R=214;
2022-04-15 13:16:06 SIGNALduino sduino_868 RAWMSG MN;D=1BE74510150101F58D2A3F6823F58D2A01110042CD317F734D01C70522AE;N=13;R=243;

Im Code von quadcorei8085 steht am Ende der CC1101 Initialisierung ein "spi_write_reg(0x7E, 0xC2);". Da ich kein 0x7E Register im CC1101 Datenblatt finden konnte, habe ich 0x40 in der Annahme eines Burstzugriffes abgezogen und dann das Register 0x3E auf 0xC2 gesetzt. Damit werden dann Nachrichten empfangen. Juhu - Nur warum ?

Zitat3D0D ist ccN = 13
3E04 ist ccmode = 4
40 - 47 ist die max 8 Zeichen Bankkurzbeschreibung ( hier ist 4045,416C,4272,436F,4400 Elro)

Ist nicht das Register 0x3D SNOP und 0x3E der Zugriff auf die PATABLE? Den Bezug auf ccN und ccmode verstehe ich an dieser Stelle nicht. Wird das im Code irgendwo umgewandelt? Ich habe eigentlich kein besonderes Handling von 0x3D oder 0x3E im Code finden können. Es funktioniert auch wenn ich 0x3D nicht initialisiere. Also hier wäre ich für Hilfe dankbar. Damich ich auch verstehe, was ich hier tue  ;)

Verstehe ich das richtig, dass die Bankkurzbeschreibung auf dem Nano verbleibt und also nicht per SPI in den CC1101 geschrieben wird? Die Funktion ist dann mehrere Protokolleinstellungen in jeweils einer Bank zu halten um dann einfach Umschalten zu können? Richtig ?

Auch bei der Berechnung von N und R aus der Nachricht grübele ich noch.


Im Code von quadcorei8085 wird das C1101 Register 0x00 (GDO2) mit 0x06 initialisiert statt 0x07 wie in deinem Ansatz. Es geht am Ende beides. Bei 0x06 bekomme ich auch Teilframes empfangen, bei 0x07 meistens nur "ganze" Frames. Das liegt wohl am vorhanden CRC Check bei 0x07, der bei den Teilframes fehlschlagen sollte. Dadurch werden zwar Frames verloren, die empfangenen Frames sind dann aber "sauber" und damit einfacher auszuwerten.

Das Protokoll an sich ist wohl doch noch etwas komplizierter als von quadcorei8085 beschrieben. Ich bekomme Frames nicht nur mit einer Länge von 0x1B sondern auch 0x1D, 0x1E und 0x24. Die Struktur sieht ähnlich aus, aber da muss noch etwas mehr Arbeit investiert werden. Welche Fernbedienung verwendet wird macht dabei schon den ersten Unterschied. Z.B. VarioTel2 vs. MultiTel2. Und natürlich senden die Aktoren auch eine Response...

Bei Neuigkeiten werde ich berichten.

Viele Grüße Michi

ZitatCW0007..2C81,2D35,2E09

Hast Du auch mal getestet ob es auch ohne das Setzen der TEST2, TEST1 und TEST0 Register funktioniert?

Zitatund dann das Register 0x3E auf 0xC2 gesetzt. Damit werden dann Nachrichten empfangen. Juhu - Nur warum ?

Bei meiner Firmware gibts einige konfigvariablen
0x3E ist ccmode, damit wird festgelegt wie die Firmware die Daten vom cc1101 empfängt:
0 - für ASK/OOK
1 - damit werden Daten vom cc1101 FIFO empfangen
2 - wie 1, aber es werden doppelte Nachrichten unterdrückt (wird bei Kopp FC verwendet)
3 und 4 wird bei La Crosse und ähnlichen Protokollen verwendet

Da bei La Crosse die einfache Empfangsroutine nicht funktioniert hat, waren bei 3 und 4 modifizierungen notwendig.
Die Routine für ccmode=4 habe ich vom CUL übernommen.

ccmode kann mit "set sduino raw ccmode=.." gesetzt werden.

Daß es mit 0x3E = 0xC2 funktioniert hat, war zufall, diesen ccmode gibt es eigentlich nicht, es dürfte ccmode=1 entsprechen.

Bitte teste mal ccmode=1 und ccmode=2, falls gleiche Nachrichten empfangen werden, müssten diese mit  ccmode=2 unterdrückt werden.

0x3D ist ccN,  N wird an der MN-Nachricht angehängt, damit kann die Parse Routine im 00_Signalduino.pm Modul die MN-Nachricht der entspechenden Protocol ID zuordnen.
N wird auch benötigt, daß beim Maple oder ESP32 mit mehreren cc1101 Modulen eine Nachricht über das passende cc1101 Modul gesendet wird.

R ist RSSI welche im 00_Signalduino.pm Modul umgerechnet wird
$rssi = ($rssi>=128 ? (($rssi-256)/2-74) : ($rssi/2-74));

ZitatVerstehe ich das richtig, dass die Bankkurzbeschreibung auf dem Nano verbleibt und also nicht per SPI in den CC1101 geschrieben wird? Die Funktion ist dann mehrere Protokolleinstellungen in jeweils einer Bank zu halten um dann einfach Umschalten zu können? Richtig ?

Ja, mit "get sduino cmdBank s" können dann die Bankkurzbeschreibungen angezeigt werden.

ZitatDas Protokoll an sich ist wohl doch noch etwas komplizierter als von quadcorei8085 beschrieben. Ich bekomme Frames nicht nur mit einer Länge von 0x1B sondern auch 0x1D, 0x1E und 0x24. Die Struktur sieht ähnlich aus, aber da muss noch etwas mehr Arbeit investiert werden. Welche Fernbedienung verwendet wird macht dabei schon den ersten Unterschied. Z.B. VarioTel2 vs. MultiTel2. Und natürlich senden die Aktoren auch eine Response...

Ja mir ist das ganze auch noch nicht so richtig klar.

Ich hab mal mit dieser Nachricht
MN;D=1BE74510050101F58D2AF58D2AF58D2A01110042CD317F734D01C705FFB1;N=13;R=220;
die Zuordung aufgeschrieben:
                                          1 2 3 4 5 6 7 8  LQI RSSI
1BE74510050101F58D2AF58D2AF58D2A0111 0042 CD317F734D01C705 FF  B1
LLcciiIIHHyyggssssssbbbbbbffffffddDD ????

LL       = packet len
cc       = index/counter (used for rolling code)
ii       = packet info
II       = packet info 2
HH       = hop information (motors can relay remote messages)
yy       = sys address
gg       = source group
ss ss ss = source address   (remote control's address)
bb bb bb = backward address (remote control's address - when remote is sending directly)
ff ff ff = forward address  (remote control's address - when remote is sending directly)
dd       = destination count
DD       = destination

Die Bedeutung von 0042 ist mir nicht klar.

Ich habe damit "CD317F734D01C705" xor_encode.py ausgeführt und dies erhalten "0x00 0x00 0x16 0x03 0x00 0x00 0x00 0x40 "

Gruß Ralf

Hi,

Ich habe VarioTel2, aber wenn die MultiEtwas ist auch kompatibel mit der Rolladen dann Ich würde vermuten dass die Encrypt/Decrypt protocol ist die gleiche.

Variotel2 ist so dass jede taste Druck/Lass wird separat geschickt.

Bei mir wenn Ich ein taste drucke dann sehe 2x 3 packete (2x weil 1 ist taste druck 1 ist lassen - so button press/release is separate)

wenn du druckst (ohne lassen) -> 3x taste-druck botschaft wird mit payload = "0x00 0x00 0x00 0x01 0x00 ... 0x00" geschickt
und sofort wenn du der Taste lassts -> 3x "gleiche" (naturlich packet ID/counter ist anders) botschaft mit payload = "0x00 0x00 0x00 0x00 0x00 ... 0x00" geschickt

vom denen Ich weisst welche bit position ist meine Taste, jede taste be mir hatte verschiedene bit position (wie erwartet).
Ich habe verschiedene kanale nicht probiert Ich glaube dass ist einfach nur "destination address" aber habe nie geprüft.

Kurzes Statusupdate

Sowohl ccmode 1 als auch 2 scheinen zu funktionieren (ccmode 3 oder 4 nicht). Ein Unterdrücken von doppelten Frames bei ccmode 2 habe ich nicht festgestellt.

Ich glaube mittlerweile, dass der Unterschied bei den Sendern eher daran liegt, ob ein Empfänger angelernt ist oder nicht (und nicht unbedingt am Typ). Bei einem angelernten Empfänger sollte man ja ein konkretes Ziel haben wohin man senden möchte...

Ein Senden einer Nachricht beim Loslassen einer Taste habe ich nicht beobachtet.

Österliche Grüße - Michi

Wenn Ich ein taste drucke und dann lasse ich sehe die 2x 3 packete:

beim druck:
29 pck_len=0x1B 0x07 0x44 0x10 0x00 0x01 0x11 0x1A 0x01 0x0D 0x1A 0x01 0x0D 0x1A 0x01 0x0D 0x01 0x11 0x00 0x03 0x40 0xB1 0x17 0x96 0xC0 0xF1 0x4B 0x35 CRC=0 LQI=b RSSI=176
29 pck_len=0x1B 0x07 0x44 0x10 0x00 0x01 0x11 0x1A 0x01 0x0D 0x1A 0x01 0x0D 0x1A 0x01 0x0D 0x01 0x11 0x00 0x03 0x40 0xB1 0x17 0x96 0xC0 0xF1 0x4B 0x35 CRC=0 LQI=a RSSI=176
29 pck_len=0x1B 0x07 0x44 0x10 0x00 0x01 0x11 0x1A 0x01 0x0D 0x1A 0x01 0x0D 0x1A 0x01 0x0D 0x01 0x11 0x00 0x03 0x40 0xB1 0x17 0x96 0xC0 0xF1 0x4B 0x35 CRC=0 LQI=b RSSI=177

beim lassen:
29 pck_len=0x1B 0x08 0x44 0x10 0x00 0x01 0x11 0x1A 0x01 0x0D 0x1A 0x01 0x0D 0x1A 0x01 0x0D 0x01 0x11 0x00 0x03 0x7C 0xEF 0x32 0x28 0x84 0x43 0xFC 0xC9 CRC=0 LQI=5 RSSI=176
29 pck_len=0x1B 0x08 0x44 0x10 0x00 0x01 0x11 0x1A 0x01 0x0D 0x1A 0x01 0x0D 0x1A 0x01 0x0D 0x01 0x11 0x00 0x03 0x7C 0xEF 0x32 0x28 0x84 0x43 0xFC 0xC9 CRC=0 LQI=5 RSSI=174
29 pck_len=0x1B 0x08 0x44 0x10 0x00 0x01 0x11 0x1A 0x01 0x0D 0x1A 0x01 0x0D 0x1A 0x01 0x0D 0x01 0x11 0x00 0x03 0x7C 0xEF 0x32 0x28 0x84 0x43 0xFC 0xC9 CRC=0 LQI=5 RSSI=175

decode(0x40, 0xB1, 0x17, 0x96, 0xC0, 0xF1, 0x4B, 0x35) = (0x00 0x00 0x20 0x00 0x00 0x00 0x00 0xC0)
wo letztes byte 0xC0 ist ein parity (wie ich erinnere, war schon fast einem jahr).

decode(0x7C, 0xEF, 0x32, 0x28, 0x84, 0x43, 0xFC, 0xC9) = (0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00)

so bit 5 im 3. byte ist die gedruckte Taste.

hier
https://github.com/appi1/elero_protocol/blob/main/main.cpp
wird das cc1101
Register 0x17 auf 0x3F gesetzt
Bit 3:2  RXOFF_MODE  Stay in RX
Bit 1:0  TXOFF_MODE  RX

und das Register 0x18 auf 0x18 gesetzt
Bit 5:4  FS_AUTOCAL   When going from IDLE to RX or TX (or FSTXON)

wenn ich das richtig überblicke, dann wird der cc1101 nur am Anfang calibriert, danach nicht mehr.
Laut Register 18 erfolgt ein calibrate nur bei einem Wechsel von idle zu RX oder zu TX.
Da laut Register 17 der cc1101 nach empfang einer Nachricht in RX bleibt, wird nie calibriert.

Bleibt die Frequenz über längere Zeit stabil, wenn kein calibrate erfolgt?


@Michi
bitte poste mal die MN-Nachrichten die Du beim Drücken der Tasten auf, ab und Stop empfängst.

encode/decode:
Gestern habe mit elero wieder gespielt muss auch sagen dass diese routine (encode/decode) momentan funkzionieren nur mit tastedruck botschaft (packet_len=0x1B und etc).
Habe die andere Arte vom botschaften nie probiert (zumbeispiel wo len=0x1D beim kanal auswahl).
-> Wenn jemand hat andere typen/arten vom botschaften dann Ich brauche ein ganze beispiel (oder log vom Serial output).

radio:
Ich bin jetzt nicht sicher dass wir CC1101 im VarioTel haben. Wie Ich mich erinnere es ist ein CC1100.
Gleiche radio aber es gibt ein paar Nuancliche unterschiede im datenblatt, nichts besonderes und seriöses.
Nur für abklarüng wollte ich das erwahnen. Ich nutze natürlich die cc1101 varianten (aus china) - so hab keine angst die sind kompatibel.


calibration:
Wie Ich gesehen habe das Atmega schlaeft am meinsten und beim battery tausch oder nach langere schlafperiode er schickt wieder die ganzem config (CC1101_Init() wird aufgerufen).
Bei mir ein esp32 liest die botschaften und laufte für tage problemlos ohne re-init.
Es gibt auch ein rückmeldung vom motoren wenn du ein command schickst, Ich schaue mal ob es auch decodierbar oder interpretierbar.

Bei mir alle andere lange funkzioniert auch, immer die letzte 8 byte ist "verschlüsselt".
Bedeutung ist naturlich nicht klar weil ich kenne die daten nicht (zum beispiel beim windspeed sensor).
Aber wenn Ich die botschafte vom fernsteuer aufnehme -> decode -> andere index nummer nutze -> encodiere -> und "zurückspiele" dann die jalusien reagieren richtig.

Hallo Michi,

liest Du hier noch mit?

Gruß Ralf

https://github.com/ioBroker/AdapterRequests/issues/60#issuecomment-1455160048