Fertig: DFF4.1 - Roto RotoTronic Dachfenster Aktor

[tuxedo KONNEKTING Mod Alle Beiträge durchsuchen Profil ansehen Schließen tuxedo]

Hallo zusammen,

nachdem die Sammelbestellung nun abgeschlossen ist, die Software mal soweit läuft und ich erstes Feedback ala "Cool, das klappt sehr gut" bekommen habe, kommt hier nun das offizielle Announcement:

Der DFF4.1 ist Einsatzbereit.

Im Wiki gibt's mehr dazu:

Allgemeine Seite zum Aktor (eher technisch, fast fertig): https://wiki.konnekting.de/index.php/DFF4.1
Benutzerhandbuch (entsteht gerade): https://wiki.konnekting.de/index.php/DFF4.1_User_Manual
Aufbauanleitung (sollte soweit fertig und vollständig sein): https://wiki.konnekting.de/index.php...g_Instructions

Wer noch Interesse an so einem Aktor hat, meldet sich bei mir. Details folgen auch noch im Wiki.

Gruß
Aexl

[pauly Forums-Einsteiger Alle Beiträge durchsuchen Profil ansehen Schließen pauly]

Hallo Alex,

in der Suite erscheint das letzte KO "Status Sperre/Alarm" eines Kanals nur wenn der nachfolgende Kanal unter "Parameter" aktiviert ist (also nicht "nicht benutzt"). D.h. dieses KO erscheint am letzten Kanal 4 nie.

Ich hoffe, Du kannst mir folgen...?

Gruß

Peter

[smarthausen Forums-Einsteiger Alle Beiträge durchsuchen Profil ansehen Schließen smarthausen]

Hallo Alex,

auf den ersten Blick erscheint die Aufgabe ja einfach: Relais starten und stoppen die Funktionen eines Roto Dachfensters mit Rototronic. Auf den zweiten und dritten Blick ist es dann nicht mehr so einfach: Die Fenster haben keine KNX Anbindung und auch keine Fensterkontakte. Dafür einen Regensensor der die Zufahrt startet. Du hast eine Hardware und Software gestaltet, mit der diese Fenster endlich eine KNX Anbindung bekommen. Die Hardware ist aufwendig, verpackt im Hutschienengehäuse sieht man davon aber nichts mehr und sie reiht sich zu den anderen Aktoren ein. Wirklich toll! Danke Dir!

Der Konnekting DFF Roto Aktor ist bei mir seit einer Woche in Betrieb und steuert zwei Roto DFF mit Fenstermechanik und Rollladenfunkltion. Hier einige Beobachtungen:

Aufbau:

Kanal 1: 1. Fenster
Kanal 2: zugehöriger Rollladen

Kanal 3: 2. Fenster, übernimmt die Einstellung von Kanal 1
Kanal 4: 2. zugehöriger Rollladen, übernimmt die Einstellung von Kanal 2

Problem: Der Fensterkanal Nr. 3 reagiert nicht mehr.

Versuch einer Lösung:

• Versucht Referenzfahrt per ETS zu starten:

Lässt sich nicht auslösen (mit ETS -> "EIN" oder "AUF" auf GA Referenzfahrt senden löst keine Aktion aus.)
Ein KO für "Zentrale Referenzfahrt" für alle Kanäle wäre praktisch. (Nach dem Programmieren tut der Aktor ja genau das.)

• Mit dem roten Knopf in der Suite eine komplette Neuprogrammierung auslösen, in der Hoffnung, eine Referenzfahrt wird ausgelöst.

Schlägt fehl: die Suite fordert manchmal zum Drücken des Programmierknopf auf, manchmal aber auch nicht.
Dann sieht man in der Konsole einen Fehler. Leicht zu erkennen auch an der der kurzen Programmierzeit.

• Neustart der Suite scheint zu helfen.

Nach Neustart: Programmierknopf gedrückt, Neuprogrammierung schlägt fehlt:

[Programmiere] Bitte 'Programmieren' Knopf drücken...
KNX Telegramm entdeckt. Verbindung scheint in Ordnung zu sein.
[Programmiere] Ein Fehler ist aufgetreten.
de.konnekting.deviceconfig.ProgramException: Problem writing individual address
at de.konnekting.deviceconfig.Program.program(Program .java:122)
at de.konnekting.suite.ProgramDialog$4.run(ProgramDia log.java:192)
at java.lang.Thread.run(Thread.java:745)
at de.konnekting.suite.BackgroundTask$1.run(Backgroun dTask.java:59)
Caused by: de.root1.slicknx.KnxException: Can not set address. no device in prog mode
at de.konnekting.mgnt.protocol0x00.ProgProtocol0x00.w riteIndividualAddress(ProgProtocol0x00.java:384)
at de.konnekting.mgnt.KonnektingManagement.writeIndiv idualAddress(KonnektingManagement.java:70)
at de.konnekting.deviceconfig.Program.program(Program .java:118)
... 3 more

[Programmiere] Fertig! Dauer: 10379 ms

Keine Referenzfahrt.

Nochmalige Neuprogrammierung geht dann plötzlich. Referenzfahrten werden ausgelöst. Alle Relais klicken der Reihe nach.

Einzelne Referenzfahrten können nun über die KO 12 und 44 ausgelöst werden.

Jetzt ist der Aktor wieder funktionsfähig.

Zentrale KO ansprechen

Nun versuche ich per ETS (sende "Runter" an KO 1) beide Fenster über das Zentral KO zu zufahren. Keine Reaktion vom Aktor.
Auch das Senden von "Ein" oder "Aus" löst an KO 1 (DTP 1.007? sollte das Format nicht 1.009 sein?) keine Aktion aus.

Öffnen / Stop / Runter

Senden von "Öffnen" an KO 9 löst richtige Aktion aus.
Senden von "Stop" an KO 10 löst richtige Aktion aus.
Senden von "Runter" an KO 9 löst schnelles zweimaliges (!) Klicken vom Relais aus. Fenster zuckt kurz, fährt aber nicht runter.

Fahrverhalten der Lüftungsfunktion

Dann löste ich für das zweite Fenster ein "Lüften" (eingestellt auf 5 Min.) aus. Fenster war schon geöffnet (20%). Aktor fährt Fenster weiter auf.
Stoppt. Nach ca. 2s fährt der Aktor das Fenster wieder auf die alte Position. Bleibt dort 5 Minuten. Relais klickt dann zweimal (!),
Fenster zuckt kurz (klar, Fenstermotor wird kurz angeworfen und sofort wieder gestoppt), bleibt auf dieser Position dann stehen.
Zufahren per Positionsbefehl (0%) funktionierte danach.

Seltsamerweise ging beim Verfahren von Fenster 2, der Positionsstatus (KO 11) von Fenster 1 "verloren". ETS empfängt keinen Wert, OpenHAB denkt das Fenster wäre zu. Nochmaliges Fahren von Fenster 1 führt nun zu einem Positionsfehler (es fährt von aktueller Position los, und fährt nicht die absolute Position an. Als ob KO 11 ohne Referenzfahrt einfach auf Null gesetzt worden wäre. (Z.B. der Timer genullt worden wäre))
Fenster lässt sich so nun nicht zufahren: via ETS ein "Schließen" führt zu zweimaligem Klicken des Relais. Fenster bleibt offen stehen. Ausgelöste Referenzfahrt zeigt gleiches Verhalten: zweimaliges Klicken, Fenster bleibt offen.
Jetzt hilft nur noch der "rote Knopf" aus der Suite. Ich probiere den "hell roten" Knopf aus: Übertragung läuft sofort. Referenzfahrten aller Kanäle werden ausgelöst.

Neuer Versuch:

Fenster 1 per "Öffnen" ... öffnen. Fenster fährt auf. Per "Stop" auf KO 10 bei 15 % gestoppt (laut KO 17). Fenster stoppt.
Laut KO 17 ist die Absolute Position nun aber plötzlich 0%. Das ist darf nicht sein. Fenster ist ja noch offen.
-> Nachfolgende Referenzfahrt führt zu zweimaligen Klacken. Fenster bleibt offen.
-> "hell roter" Knopf in der Suite notwendig, damit eine funktionierende Referenzfahrt ausgelöst wird.

Zusammenfassung:

• Referenzfahrten funktionieren nicht immer (nur zuverlässig mit Suite)
• "Runter" Befehl funktioniert nicht.
• Zentralobjekte lösen keine Aktion aus. (Sehr schade, damit könnte man schnell beide Fenster zufahren.)

OpenHAB

Derzeit verwende ich nur OpenHAB (iOS App) und dessen Slider Objekt um die Fenster zu bewegen. Das funktioniert sehr gut (bis eben auf die oben genannten Fälle.): der Slider zeigt die aktuelle Position des Fensters an, bewegt man den Slider auf eine neue Position, bewegt sich das Fenster und der Slider zeigt den aktuellen Verfahrstatus an.

Vorheriger Aufbau: MDT Jalousieaktor und Glastaster

Leider schaffe ich es nicht, den Aktor mit einen MDT Glastaster anzusteuern. Eventuell versteht der Aktor nicht die vom Glastaster gesendeten Werte.
Bisher hatte ich einen MDT 24V Jalousieaktor angeschlossen und eine Verfahrzeit von 1s eingestellt. Dann konnte ich per "langem" Tastendruck das Fenster/Rollladen auffahren und per "kurzem" Tastendruck" das Fenster zufahren. Natürlich war damit nicht möglich eine bestimmte Position anzufahren, noch gab es weitere Statusmeldungen. Das funktionierte aber zuverlässig. Nachdem ich höchst glücklich diesen Aktor rausgeworfen hatte, werde ich ihn wohl wieder parallel dazu einbauen.

Vielleicht kann jemand dieses Verhalten nachstellen und macht andere Beobachtungen als ich.

Mit vielen Grüßen
Richard

[tuxedo KONNEKTING Mod Alle Beiträge durchsuchen Profil ansehen Schließen tuxedo]

Hallo zusammen,

bin seit gestern Nacht aus dem Kurzurlaub zurück. Werde mich kommende Woche mal näher mit euren Anliegen beschäftigen.
Mein eigener Aktor liegt noch als "Foto-Model" auf dem Fensterbrett. Werde diesen die Tage in den Verteiler einbauen und einen zweiten zum experimentieren auf dem Schreibtisch aufbauen.

Eine erste Antwort hab ich aber schon:

in der Suite erscheint das letzte KO "Status Sperre/Alarm" eines Kanals nur wenn der nachfolgende Kanal unter "Parameter" aktiviert ist (also nicht "nicht benutzt"). D.h. dieses KO erscheint am letzten Kanal 4 nie.

Ich hoffe, Du kannst mir folgen...?

Da ist wohl ein Fehler in der kdevice-xml unter den "Dependencies". Vielleicht hat ja jemand vor mir Zeit da mal rein zu schauen wo die Verknüpfung falsch ist?
Anleitung hier: https://wiki.konnekting.de/index.php...ce_Description

Fehler dieser Art kann man auch prima auf Github im entsprechenden Projekt melden. Dann wird der Fehler, die Diskussion um den Fehler und die zugehörige Code-Änderung gleich an der passenden Stelle getracked.

Das DFF-Projekt findet man hier: https://github.com/KONNEKTING/DFF4.1
Neue Fehler meldet man dann bei "Issues" mit new issue

Gruß
Alex

[tuxedo KONNEKTING Mod Alle Beiträge durchsuchen Profil ansehen Schließen tuxedo]

Hallo Richard,

bin leider noch nicht dazu gekommen die von dir genannten Fehler zu debuggen. Hatte zu viele privaten Termine die letzten Tage.
Kommendes WE wird's zeitlich auch nochmal eng, aber dann müsste es besser werden, wenn nicht das Wetter so heiß wird dass die Debug-Session am PC zur Qual wird.

Sitze gerade aber wieder davon und hab ein klein wenig zeit mich da rein zu denken. Ich berichte wenn ich mehr weiß.

Gruß
Alex

[tuxedo KONNEKTING Mod Alle Beiträge durchsuchen Profil ansehen Schließen tuxedo]

Sehe gerade dass etwas in der Positionsberechnung nicht stimmt. Wenn ich das Fenster öffne (von Hand per Knopf) und bei ca. 20% stoppe, und wieder schließen will, meint der Sttaus er wäre bei 0% und fährt quasi gar nicht.

--> Wurm drin.

[tuxedo KONNEKTING Mod Alle Beiträge durchsuchen Profil ansehen Schließen tuxedo]

Ach ja:

Der Aktor gibt Status-Meldungen über den USB-Port aus. Dort kann man sich ggf. mehr Details anschauen. Einfach MiniUSB-Kabel anschließen und ein Serielles Terminal mit 115200-8-E-1 aufmachen und mitschneiden. Die Arduino IDE geht natürlich auch. Da kann man auch gleich Code-Änderungen testen :-)

Gruß
Alex

[tuxedo KONNEKTING Mod Alle Beiträge durchsuchen Profil ansehen Schließen tuxedo]

Ein Fehler hab ich nun entdeckt:
Wenn die KnxEvents von den KOs eingehen, wird aus dem KO-Index errechnet um welchen Kanal es sich handelt. Hier geht etwas schief und wenn man Kanal 3 ansteuert landet der Befehl bei Kanal 4.

[tuxedo KONNEKTING Mod Alle Beiträge durchsuchen Profil ansehen Schließen tuxedo]

Hab das Repo auf Github mal auf den neusten Stand gebracht. Die KO-Index-Berechnung ist nun repariert.

Wenn ich an die GA von KO41 ein Kommando sende, landet dies auch beim richtigen KO am richten Kanal.

Die anderen Phänomene muss ich mir getrennt anschauen.

Wer den aktuellen Stand aufspielen will:

* Sourcecode von https://github.com/KONNEKTING/DFF4.1 laden
* Sourcecode in Arduino IDE öfnen
* Arduino/Genuino Zero (native USB) als Device einstellen
* Über den Library Manager in der Arduino IDE KONNEKTING Device Library 1.0.0beta4a runterladen
* Code auf den Aktor laden

ggf. schlägt das Hochladen auf den Aktor fehl. Da klappt es ab und an mit dem Reset durch die Arduino IDE nicht. Beim zweiten Versuch klappts dann aber. Wieso und warum das manchmal auftritt kann ich nicht sagen. hab das verhalten aber auch an einem echten Arduino schon bemerkt.

[tuxedo KONNEKTING Mod Alle Beiträge durchsuchen Profil ansehen Schließen tuxedo]

Aufbau:

Kanal 1: 1. Fenster
Kanal 2: zugehöriger Rollladen

Kanal 3: 2. Fenster, übernimmt die Einstellung von Kanal 1
Kanal 4: 2. zugehöriger Rollladen, übernimmt die Einstellung von Kanal 2

Problem: Der Fensterkanal Nr. 3 reagiert nicht mehr.

--> Sollte mit der korrigierten KO Indexberechnung nun funktionieren. Ich kann bei mit mit dieser Konstellation jedenfalls nun Kanal 3 ansprechen.

Versucht Referenzfahrt per ETS zu starten:

Die Fehlberechnung des Index spielt hier natürlich auch eine rolle, da alle Indizes aller Kanäle davon betroffen sind. Habs bei mir getestet. Funktioniert soweit.

Mit dem roten Knopf in der Suite eine komplette Neuprogrammierung auslösen, in der Hoffnung, eine Referenzfahrt wird ausgelöst.
Schlägt fehl: die Suite fordert manchmal zum Drücken des Programmierknopf auf, manchmal aber auch nicht.

Der rote Knopf in der Suite fordert _immer_ auf den Button zu drücken. Da gibt's kein "geht nur manchmal". Kann es sein dass du hin und wieder auch die anderen Buttons benutzt hast? Lediglich der rote erfordert den Prog-Knopf am Gerät selbst. Alle anderen sprechen das Gerät direkt an und versetzen es in den Programmiermodus.

Dann sieht man in der Konsole einen Fehler. Leicht zu erkennen auch an der der kurzen Programmierzeit.
Neustart der Suite scheint zu helfen.
Nach Neustart: Programmierknopf gedrückt, Neuprogrammierung schlägt fehlt:

[Programmiere] Bitte 'Programmieren' Knopf drücken...
KNX Telegramm entdeckt. Verbindung scheint in Ordnung zu sein.
[Programmiere] Ein Fehler ist aufgetreten.
de.konnekting.deviceconfig.ProgramException: Problem writing individual address
at de.konnekting.deviceconfig.Program.program(Program .java:122)
at de.konnekting.suite.ProgramDialog$4.run(ProgramDia log.java:192)
at java.lang.Thread.run(Thread.java:745)
at de.konnekting.suite.BackgroundTask$1.run(Backgroun dTask.java:59)
Caused by: de.root1.slicknx.KnxException: Can not set address. no device in prog mode
at de.konnekting.mgnt.protocol0x00.ProgProtocol0x00.w riteIndividualAddress(ProgProtocol0x00.java:384)
at de.konnekting.mgnt.KonnektingManagement.writeIndiv idualAddress(KonnektingManagement.java:70)
at de.konnekting.deviceconfig.Program.program(Program .java:118)
... 3 more

[Programmiere] Fertig! Dauer: 10379 ms

Bitte stelle sicher, dass du die Suite im Debug-Modus startest (es gibt zwei Start-Files. eine mit "Debug" im Namen und eine ohne). Startest du den falschen Modus passt das Timing nicht mehr und es kommt vermehrt zu genau diesen Problemen.

Zentrale KO ansprechen

Nun versuche ich per ETS (sende "Runter" an KO 1) beide Fenster über das Zentral KO zu zufahren. Keine Reaktion vom Aktor.
Auch das Senden von "Ein" oder "Aus" löst an KO 1 (DTP 1.007? sollte das Format nicht 1.009 sein?) keine Aktion aus.

DPT1.007 hab ich auf 1.009 korrigiert. Aber das ändert an der Implementierung nichts. Das ändert nur die Semantik in der ETS.
Auch hier hat die falsche Index-Berechnung zugeschlagen. Aber so ganz funktioniert's wohl doch noch nicht. Ich bin da aber dran.

Den Rest schau ich mir auch noch an.

Aber eine bitte:

Beim nächsten Fehler-Report keinen langen zusammenhängenden Text schreiben, sondern versuchen das Problem ggf. in Teilprobleme zu zerlegen (ggf. ist ja nicht nur ein BUg, sondern mehrere verschiedene?). Dann kann man die getrent betrachten. So muss ich erstmal alle Infos zerlegen und schauen um was es denn nun genau geht.

Die nächste bitte wäre, Probleme - wie schon weiter oben beschrieben - im Issue-Tracking aufzumachen. Dort lässt sich das besser nachverfolgen.

Und da wir ja noch in einer "frühen Version" der Firmware sind, wäre es ganz hilfreich ein Log direkt vom Aktor zu bekommen. Auch hier - wie gesagt: USB Kabel dran, Arduino IDE öffnen und den Serial Monitor starten und mitschreiben was der Aktor so sagt. Aber hier keine 5h lange Aktion mitschneiden, sondern von Aktor-Sart bis hin zun Fehler mitloggen. D.h. auch nicht einen vermeintlich interessanten Ausschnitt herauskopieren. Sonst fehlt vielleicht doch noch ein wichtigs Detail.

So, das war's für's erste. Ich werde jetzt meinen Aktor weiter unter die Lupe nehmen und die restliche Fehlerbeschreibung durchgehen.

gruß
Alex

[tuxedo KONNEKTING Mod Alle Beiträge durchsuchen Profil ansehen Schließen tuxedo]

Die Zentralen KOs hab ich denke ich nun auch im Griff. Die hatte ich in der tat nicht tiefgreifend getestet.

Intern habe ich nur den Index vom Zentralen KO auf das jeweils Channel-zugehörige KO gemapped. D.h. "Zentral auf/zu" wurde auf "Channel auf/zu" umgerechnet. Dabei ging aber die Info verloren, dass es vom Zentralen KO kam und der Wert der am ComObj Event dran hing war dann der falsche.

Hab das nun korrigiert. Zentral auf/zu funktioniert nun. Die restlichen zentralen KOs sollten damit dann auch funktionieren. Muss aber noch vollends getestet werden.
An diesem Punkt sieht man auch schon: Eigentlich gehört hier ein Unit-Test oder etwas in der Art her der die Firmware auf dem Gerät testet. Aber davon hab ich noch kein Plan. Ist sicher aufwendig. Wenn jemand Ideen hat: Her damit.

Der Bugfix bzgl. der zentralen KOs wandert gleich ins Git.

smarthausen

Forums-Einsteiger

Alle Beiträge durchsuchen

Profil ansehen

Schließen

smarthausen Vielleicht hast du ja Zeit und Lust im Wiki ein Firmware-Update Anleitung zu basteln? Der richtige Platz hierfür wäre dieser: https://wiki.konnekting.de/index.php...irmware_Update (sollte ein allgemeiner Artikel werden. Gerne kann man den aber für die einzelnen Device-Typen einzeln ausprägen)

[smarthausen Forums-Einsteiger Alle Beiträge durchsuchen Profil ansehen Schließen smarthausen]

Hallo Alex,

Danke für Deine Verbesserungen. Bin gespannt. :-)

* Wer den aktuellen Stand aufspielen will:

Sourcecode von https://github.com/KONNEKTING/DFF4.1 laden

Lädt man den Code per Browser als ZIP Datei herunter, sollte man diese in einen Ordner mit dem Namen "DFF4.1" entpacken.

* Sourcecode in Arduino IDE öfnen

Ardunio IDE herunterladen, dann direkt unter dem Menü "Werkzeuge", dann "Board", den "Boardverwalter" öffnen, dort nach "Zero" suchen und das Paket "Arduino SAMD Boards" installieren. Windows fragt dann um Erlaubnis, Treiber zu installieren.

* Arduino/Genuino Zero (native USB) als Device einstellen
* Über den Library Manager in der Arduino IDE KONNEKTING Device Library 1.0.0beta4a runterladen

Öffnet man im Ordner "DFF4.1" die Datei "DFF4.1.ino" und klickt im oberen Abschnitt "Includes" auf die drei aufgeführten Links, öffnet sich der Bibliotheksverwalter. Dort können dann die Librarys installiert werden.

* Code auf den Aktor laden

Bevor zum Schaltkasten rennt, einfach mal auf den "Überprüfen" Haken (links oben) klicken und schauen ob man das Programm auf den Arduino bringen könnte. Vorher noch das richtige Board einstellen: "Arduino/Genuino Zero (Native USB Port)"

Da meckert meine IDE leider über #include "Memory.h". Eine solche Datei finde ich auf meinen Rechner nicht. Habe ich da was übersehen? ... Ja! Einfach in der Datei "Memory.h" (zu finden bei den Reitern oben in der IDE) auf den Link "#include <extEEPROM.h> // http://librarymanager/All#extEEPROM Version 3.4.0" klicken und dort diese Bibliothek einbinden.

Jetzt klappt das Kompilieren.
Danach per USB Kabel den Aktor mit dem Computer verbinden. Zuerst wurde das Board nicht gefunden: Arduino IDE neu starten (Treiber wurden neu installiert!) und im Menü "Werkzeuge" den richtigen Port für das Board einstellen.

Dann konnte ich alles auf das Board laden:

Verify 62000 bytes of flash with checksum.
Verify successful
done in 0.060 seconds
CPU reset.

Später teste ich die Änderungen dann.

Mit vielen Grüßen!

Richard

[smarthausen Forums-Einsteiger Alle Beiträge durchsuchen Profil ansehen Schließen smarthausen]

Test: der Aktor lässt sich nicht mehr programmieren. Die rote LED leuchtet nicht mehr auf. Die anderen grünen LEDs leuchten. Mich wundert: warum hat der Aktor nach der Neuprogrammierung keine Referenzfahrt gestartet? Habe den Aktor auch mal vom KNX Bus genommen und gewartet. Irgendwas hängt. Hmpf.

[Programmiere] Bitte 'Programmieren' Knopf drücken...
[Programmiere] Ein Fehler ist aufgetreten.
de.konnekting.deviceconfig.ProgramException: Problem writing individual address
at de.konnekting.deviceconfig.Program.program(Program .java:122)
at de.konnekting.suite.ProgramDialog$4.run(ProgramDia log.java:192)
at java.lang.Thread.run(Thread.java:745)
at de.konnekting.suite.BackgroundTask$1.run(Backgroun dTask.java:59)
Caused by: de.root1.slicknx.KnxException: Can not set address. no device in prog mode
at de.konnekting.mgnt.protocol0x00.ProgProtocol0x00.w riteIndividualAddress(ProgProtocol0x00.java:384)
at de.konnekting.mgnt.KonnektingManagement.writeIndiv idualAddress(KonnektingManagement.java:70)
at de.konnekting.deviceconfig.Program.program(Program .java:118)
... 3 more

[Programmiere] Fertig! Dauer: 13026 ms

[tuxedo KONNEKTING Mod Alle Beiträge durchsuchen Profil ansehen Schließen tuxedo]

Mist, mein Fehler. Der Aktor wartet auf eine USB Verbindung. Hab das für Debug-Zwecke eingeschaltet und vergessen wieder auszuschalten. Sorry.

Diese Zeile hier auskommentieren und neu aufspielen:

https://github.com/KONNEKTING/DFF4.1...DFF4.1.ino#L64

Gruß
Alex

[higgx Forums-Einsteiger Alle Beiträge durchsuchen Profil ansehen Schließen higgx]

Hallo zusammen,

habe schon vor einer Weile mal mit Alex wg. der Verfügbarkeit von weiteren Bausätzen für den DFF Aktor gemailt.
Leider scheinen nicht mehr genug Teile für weitere komplette Bausätze derzeit verfügbar zu sein.
Deshalb wollte ich mal auf diesem Weg fragen, wer denn außer mir noch Interesse an solchen Bausätzen hätte, dann könnte man den Alex vlt. zu einer weiteren Sammelbestellung überreden ?!?

Da es vor allem an den Gehäusen zu scheitern scheint, wollte ich fragen, ob es nicht irgendwie die Möglichkeit gäbe, die Teile in 3D zu drucken? Dann wäre man doch nicht so abhängig von einer Mindestbestellmenge, oder?

Würde mich über Rückmeldungen von weiteren Interessierten hier im Forum freuen!

viele Grüße
Roland