Hallo zusammen,
ich bin einer der Personen die an einem Community-Zusatzdock für die R2 arbeiten. Meine Arbeit basiert auf der Basis von Petchmaker, hat aber mittlerweile die volle Gundfunktionalität des Original-Docks implementiert (Erkennung und Einrichtung über Bluetooth, Update der WLAN Settings über die Remote, Ändern des Dock-Names, …).
Wobei ich aber etwas Hilfe brauche, ist beim Hardwaredesign. Ich habe mir einen gebrauchten Harmony Hub gekauft (kostet 15€) und mein Plan ist es, das Gehäuse weiter zu verwenden, aber die Platine auszutauschen und so ein “UC Dock in Harmony Gewand” zu bauen.
Meine HTL Zeiten in denen wir Schalungsdesign gemacht haben sind schon einige zehn Jahre her und wie ich sehe ist hier ganz viel Know-How verfügbar.
Deshalb mal hier die Frage nach Unterstützung. Z,b,. Led Auswahl, FET/Transistorschaltung (eure Diskussionen über EMV und Flankensteilhiet hat mich etwas verunsichert ), Platinendesign, … Überall könnte ich Unterstützung gut brauchen.
Das soll alles in das GitGub Repo rein (GitHub - itcorner/ESP32-IRBlaster-UCR2: An ESP32 IR blaster implementing the UCR2 dock websocket API.), damit es andere nachbauen können.
Was haltet ihr von der Idee? Jemand Interessiert?
Eine sehr schöne Idee. Zumal man sich- wenn die Schaltungen vorliegen - für kleines Geld die Platine hoch professionell anfertigen lassen kann. Dann noch in ein eh vorhandenes Harmony Dock „reinklicken“ und fertig. Ich könnte eventuell auch ein eigenes Gehäuse entwerfen.
Technisch/ fachlich kann ich da leider nichts beisteuern, aber bei der Fertigung später bestimmt.
IR-LED:
Meine letztliche Auswahl (SFH4726AS oder Äquilvalent) ist in dem schon verlinkten Dokument beschrieben und begründet.
Bei Gelegenheit kann ich mir die Augensicherheit noch genauer ansehen, das ist aber gewiss kein großes Problem.
Transistor:
Hier bevorzuge ich (wie auch UC) Logik-Level-Mosfets statt (Low VCE(sat)) Bipolar-Transistor, weil mit ihnen oft ein niedrigerer Spannungsabfall und quasi leistungsloses Schalten realisierbar ist.
Den Fet würde ich an die Betriebsspannung legen, damit die LED-Kathode über den Kabelschirm an GND liegt =Sleeve des Klinkensteckers, Tip ist LED-Anode.
Das ist zwar inkompatibel mit den anderen Varianten, doch meiner Ansicht nach aus EMV-Sicht sinnvoller und im Hinblick auf den LED-Anschluss auch intuitiver.
Der Ansteuerpegel ist aus Sicht des ESP32 high = LED on.
Flankensteilheit:
Die kann man gut mit dem Gate-R verringern und, wenn man möchte, noch ein induktives Element in den Drain-Zweig einfügen (Ringing vermeiden!).
Die Resetverzögerung (verhindert LED-Einschalten beim Start) kann man mit R1/C1 einstellen, liegt momentan um 400µs. Sie ist für mehrere LEDs nur einmal nötig, lediglich D3 ist entsprechend oft einzusetzen.
Das Amobead ist anfangs ungesättigt, mit höherer Induktivität und soll mit dem LED-Strom sättigen, mit niedrigerer Induktivität. Ob die ~700mA dafür genügen, ist mir noch nicht bekannt, im Datenblatt fand ich das nicht konkret. Die Idee entstammt AoEx, das muss ich mal testen, ein paar Exemplare liegen mir vor.
Gruß, Timo
23.02.2024 edit:
Schaltung modifiziert für ESP-I/O = high ==> LED = on
danke für deinen input. habe eine frage: kann man die von dir vorgeschlagene led auch nach vorne oder zur seite ausrichten?
der original harmony hub hat 2 leds nach oben, die können vermutlich durch deinen vorschlag ersetzt werden. aber was mache ich mit den leds nach vorne, bzw mit denen zur seite?
ja, die Platzierung der (Weitwinkel-) LED ist im Wesentlichen beliebig, wobei starke Abschattungen in Richtung zu bedienender Empfänger zu vermeiden sind. Die Vorderseite bietet sich an.
Die Silikonabdeckung der LED sollte mechanisch geschützt beiben, insofern wäre ein Versenken wünschenswert und Abdecken mit PMMA, Glas o.ä. optimal.
Das ist freilich mechanisch aufwändiger.
Auch im Harmony Hub wäre eine einzelne SFH4726AS A01 mit entsprechend hohem Strom ausreichend, bin ich mir sicher. Vermutlich werden auch hier alle LEDs synchron betrieben, das wäre zu prüfen. In dem Falle sind sie durch eine einzelne Power-LED ersetzbar.
Genau in der Mitte ist noch etwas Platz…
Meinen Hub hatte ich bislang nicht offen, ist eine Idee, wenn ich mal nix zu tun hab.
Ist schon die Schaltung bekannt, zumindest der LED-Treiber? Reeingineering ist mühsam und fehleranfällig…
Solange der Hub jedoch seinen Dienst anstandslos versieht, sehe ich keine dringende Veranlassung zur Änderung. Außer Forschungsdrang vielleicht.
Leider ist seit drei Wochen mein Handteil defekt, es rebooted pausenlos. Wird aber geladen und lässt sich ausschalten. Also nur zu 90% kaputt.
Ein Ticket ist gesetzt, immerhin erhielt ich eine positive Antwort…
Frage in Zusammenhang mit Activity Groups und Home Assistant:
Ich schalte meinen Beamer über die Home Assistant Integration an und aus. Die Funktionen werden über eine Entität input_button an HA geschickt, HA schaltet dann den Beamer per IP. Funktioniert auch soweit sauber.
Die Kommandos dazu habe ich als POWER_ON und POWER_OFF in der jeweiligen Ein- und Ausschaltsequenz der Aktivität drin und alle Aktivitäten in einer Aktivitätsgruppe zusammengefasst. Funktionert auch soweit, der Beamer wird richtig geschaltet, wenn man von “Nichts aktiv” auf eine Aktivität mit Beamer geht.
Auch der Wechsel innerhalb von Beamer-inkludierten Aktivitäten oder innerhalb TV-inkludierten Aktivitäten: alles einwandfrei (von gelegentlichen Hängern mal abgesehen, aber das ist ein anderes Thema).
Was nicht funktioniert ist, wenn man von einer Aktivität ohne Beamer (also mit TV oder von Musik hören) auf eine Aktivität mit Beamer wechselt. Der TV wird sauber ausgeschaltet, der Beamer aber nicht an (bzw. auch nicht aus, wenn man von Beamer-Aktivitfät auf TV_Aktivität wechselt).
Ach ja, Aktivitätsgruppe steht auf “modifizierte Ausschalt-Sequenz ausführen”
Wenn ich das noch schaffe bin ich nah am “Frau akzeptiert die Neue” .
Was hab ich übersehen? Hat einer nen Tipp? Oder hab ich damit ein in Firmware 1.6.10 noch offenes Thema erwischt.
Ich vermute es liegt daran, dass es zwei einzelne Befehle sind. Die Logik mit dem Namen funktioniert glaube ich nur bei IR-Befehlen und nicht über IP. Schau mal in die Logs mit Debug Priorität. Dort ist die genaue modifizierte Sequenz zu sehen, die ausgeführt wird. Mit meiner Leinwand funktioniert das aber z.B., obwohl diese Entitäten offiziell noch nicht unterstützt werden in den Aktivitätsgruppen. Es reicht aber, wenn die Ein- und Ausschaltbefehle wie bei dir in den Ein- und Ausschaltsequenz sind. Kann auch sein, dass die Remote einen falschen Status intern gespeichert hat. Dann solltest du das in den Logs sehen.
Danke, das hat schon mal geholfen den Aktionen etwas genauer auf die Finger zu schauen.
Sieht so aus, als ob die Logik laut Log richtig ist und auch die HA-Entitäten so geschaltet werden wollen wie sie sollen. Da es aber mal funktioniert, mal (leider häufiger) nicht, schieb ich es im Moment auf den sehr langsame Reconnect der Verbindung zu HA wenn die Remote 2 aus dem Sleep kommt. Hab im GIT der HA-integration aber schon eine Änderung gesehen, die das wahrscheinlich adressiert/verbessert.
Ich wart dann mal auf die nächste FW.
Thema Apple TV Intergration: soweit funktioniert eigentlich alles, aber wie oft passiert es, dass ich die Lautstärke nicht mehr regeln kann. Auf dem Display erscheint nur die Lautstärke „50“ und reagiert dann auf keine Eingabe der Lautstärke mehr bzw. Bei Änderung bleibt es immer bei „50“. Alle anderen Tasten funktionieren aber noch. Hier hilft dann nur ein Neustart der R2. Hat das jemand auch und vielleicht gelöst bekommen ?
Ich versuche seit Wochen die Philips Hue Integration ans Laufen zu kriegen.
Die Bridge wird wohl gefunden, aber nachdem ich die Taste an der Bridge betätigt und bestätigt habe kommt immer nur ein “Hoppla”.
Gibt es hier irgendeinen Trick den ich übersehen habe?
Schau mal in die Logs unter Einstellungen/Protokoll mit Priorität DEBUG und Core und Hue Integration ausgewählt. Bei mit funktioniert Hue ohne Probleme
Hallo Kenny,
hab ich gemacht. Die bridge wird mit den korrekten Einstellungen gefunden. incl IP und Namen. Als letzte Meldung kommt dann ‘No config file found. Starting with empty config.’.
Das wars dann. Es gibt eigentlich keine Fehlermeldung.
Die Hue bridges waren schon unter der Harmony zickig in der Einrichtung. Ich vermute hier tatsächlich eher das „Problem“ bei Philips als bei der Remote.
Im Harmony Setup musste man schnell sein, die Bridge in den pairing Mode versetzen und innerhalb von ein paar Sekunden die Kopplung initiieren. Bei dir scheint der Handshake zu klappen. Ohne weitere Infos aus dem log wird es aber schwierig mit der Diagnose.
), Platinendesign, … Überall könnte ich Unterstützung gut brauchen.
