360 Grad IR WLAN Gateway

Begonnen von gloob, 08 Juni 2017, 21:16:36

Vorheriges Thema - Nächstes Thema

Sven9719

#495
Hallo, hat zufälliger weise schonmal jemand ein Stiebel Eltron Splot-Raumklimasystem CAWS 26 oder 36 (weiß nicht genau welche, die Anleitung ist für beides) mit dem IR-Gateway angesteuert?
Mit den IR Signalen die ausgelesen werden bekomme ich es nicht hin, da komischerweise ständig andere Signale mit gesendet werden.

Mit freundlichen Grüßen
Sven

Beta-User

(Sorry, wenn das schon mal gefragt worden sein sollte): Gibt's eigentlich eine Möglichkeit, die Sendeleistung ohne Gefahr für die Dioden etwas zu erhöhen?
Ich würde gerne aus meinem AV-Schrank heraus senden, das Signal müßte dann von der gegenüberliegenden Wand (ca. 3,5m entfernt) reflektiert ausreichen, um z.B. meinen Yamaha-Receiver zu schalten...
"As is" funktioniert das leider nicht so ganz.

Danke vorab,
Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

gloob

Die LEDs sind aktuell schon ohne Vorwiderstand verbaut. Mehr Leistung bekommst du bei 5V nicht raus.

Die Strecke schaffe ich bei mir allerdings auch ohne Optimierungen. Hast du mal probiert das Gateway ein bisschen zu drehen? Hast du noch ein Glas vor dem Gateway?
Raspberry Pi 3 | miniCUL 433MHz | nanoCUL 868 MHz | nanoCUL 433 MHz | MySensors WLAN Gateway | LaCrosse WLAN Gateway | SignalESP 433 MHz | SignalESP 868 MHz | HM-MOD-UART WLAN Gateway | IR - 360 Grad WLAN Gateway

Beta-User

Danke für die Info.

Drehen hatte ich schon versucht, das hat nicht zum Erfolg geführt. Evtl. ist auch der Receiver etwas "träge" und benötigt bei schwächerem Signal ggf. einfach mehr Wiederholungen?

Mit direkter Sichtverbindung war es kein Problem gewesen, aber da habe ich keine 5V... Werde das mal Testen, oder hat da jemand Erfahrung?

[OT]
Ich habe das Teil übrigens auf Basis einer puren MQTT-Lösung eingebunden. Bin zwar noch nicht ganz fertig, aber kurz die Grundzüge:
Code ist im wesentlichen von hier: https://github.com/enc-X/mqtt-ir-transceiver
Anzupassen waren nur die verwendeten PINs in globals.h, die main.cpp habe ich der Einfachheit halber in src.ino umbenannt, dann ging das ganze mit der Arduino-IDE zu kompilieren.

MQTT-Device angelegt, autoSubscribeReadings auf _bridge_/receiver/+/+, Tasten gedrückt => diverse Readings für die unterschiedlichen Protokolle anlegen lassen; dann auf _bridge_/receiver/+/+/+ erweitert, dann war auch die Panasonic-FB vom Beamer da :) .

Senden ist etwas tricky, weil die firmware dann wieder Sendecodes bzw. eine Topic-Struktur benötigt, die gleich aufgebaut sind, nur eben mit "sender" statt "receiver". Das klappt also nicht direkt mit dem MQTT-Device (ohne Änderung des publishSet-Attributs), wenn ich unterschiedliche FB-Protokolle auf ein Remotecontrol-Modul mappen will. Die Lösung werde ich daher entweder ähnlich machen wie hier, also mit einem Dummy samt zugehörigem MQTT-Bridge-Device (es sei denn Alexander ist mit seiner generischen Bridge schneller):
OpenMQTTGateway - IR, RF, BLE, Temp, Hum + Lux am ESP8266

Alternativ könnte ich auch RAW-Codes in das Remotecontrol-Device einbauen bzw. auf der Bridge speichern.
Mal sehen, was einfacher ist und wie ggf. die Wiederholungen hinzubekommen sind...[/OT]
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Pfriemler

Zitat von: Beta-User am 26 April 2018, 09:30:54
Ich würde gerne aus meinem AV-Schrank heraus senden, das Signal müßte dann von der gegenüberliegenden Wand (ca. 3,5m entfernt) reflektiert ausreichen, um z.B. meinen Yamaha-Receiver zu schalten...
"As is" funktioniert das leider nicht so ganz.
Logisch, wenn die verwendeten IR-Dioden klarer Bauart sind und so ein Rundabstrahlung abdecken. Nichts hindert Dich aber, die Dioden alle in eine Richtung zu bündeln, aus dem Schrank heraus. Allerdings frage ich mich, ob nicht ein kleiner lokaler Reflektor, etwa ein angeleuchteter weißer verdeckter Streifen über dem Yammi, nicht genauso effektiv ist.

Versuch macht kluch.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Beta-User

Hallo Pfriemler,

Danke für diesen Gedanken. Bei so einer Lösung müßte ich zwar vermutlich etwas sehr improvisieren, der Receiver paßt von der Tiefe her halt grade so rein, und bei dem scheint der IR-Empfänger auch noch ziemlich weit im (Metall-) Gehäuse versenkt zu sein. Daher ist bei dem indirekt von vorne mit Reflektor im Schrank sehr schwierig , aber irgendwie findet sich immer eine Lösung.

Was noch eine Option wäre: Der Receiver hat hinten einen Klinkeneingang für entfernte IR-Empfänger. Hat jemand Erfahrung bzw. kann mir sagen, ob es möglich wäre, einfach eine 3,5-er Klinke statt einer der IR-Dioden anzuklemmen? Dann müßte ich allerdings vorher testen, ob das bei den anderen Geräten derselbe Hickhack ist, oder ob das da besser geht. Die bekomme ich aber notfalls tiefer in den Schrank rein...

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Pfriemler

Die IR-Dioden senden Pulse einer 38-kHz-Modulation. Wenn der Klinkeneingang Pulse verträgt, dann zumindest ohne die Pulsmodulation, dazu kommt die richtige Pegellage (low, high?) - etwa das, was der Ausgang eines IR-Empfängers liefert, wie er auf dem Blaster verbaut ist. Dessen Signal wäre auch evtl anzapfbar, der der wird bei jeder Sendung reichlich mitbeleuchtet. ..

Gesendet von meinem SM-G900FD mit Tapatalk

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

gloob

Fun könntest auch eine IR Diode mit einem kleineren Winkel verbauen. Dann strahlt die LED mehr Leistung in die eine Richtung.
Raspberry Pi 3 | miniCUL 433MHz | nanoCUL 868 MHz | nanoCUL 433 MHz | MySensors WLAN Gateway | LaCrosse WLAN Gateway | SignalESP 433 MHz | SignalESP 868 MHz | HM-MOD-UART WLAN Gateway | IR - 360 Grad WLAN Gateway

Beta-User

#503
Moin zusammen,

Danke für die Anregungen.

Was die Sendedioden angeht, bin ich etwas verloren... Wenn der Abstrahlwinkel signifikant kleiner werden soll, gehen jedenfalls bei den bei Conrad gelisteten Dioden auch die Wellenlängen runter, und (vermutlich) 5° Verbesserung z.B. beim Vishay TSUS 5202 (950nm) ist zwar einiges, aber ob das reicht? Da klingen 5° beim OSRAM SFH 4555 besser, aber eben dann auf 860nm.
Die Frage wäre, ob nicht das Ausschlachten einer alten FB mehr bringt, sowas sollte noch im Keller zu finden sein und die dortigen Dioden scheinen teilweise bei <4,5V noch bessere Sendeergebnisse zu bringen.

Den Empfänger rückwärts anzuzapfen klingt auch gut. Etwas weitergehend könnte ich ja einfach mal einen Klinkenstecker einstöpseln und sehen, ob es nicht möglich ist, da einen zusätzlichen Empfänger ranzubasteln; Empfangsdiode dürfte ich noch irgenwo eine rumliegen haben, da einen pulldown dran, sofern ich 3-5V+Gnd finde?

Ist aber langsam sehr OT hier, sorry...

Gruß, Beta-User

EDIT: habe jetzt mal einige VISHAY TSAL6200 beim freundlichen Chinesen geordert, das eilt alles ja nicht. Sind mit bis zu 160mA, 17° angegeben; zu vermuten ist, dass auf dem Blaster die "Standard"-Teile mit 20° und 15mA drauf sind. Werde berichten, wird aber dauern.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

gloob

#504
Zitat von: Beta-User am 27 April 2018, 09:38:10
Moin zusammen,

Danke für die Anregungen.

Was die Sendedioden angeht, bin ich etwas verloren... Wenn der Abstrahlwinkel signifikant kleiner werden soll, gehen jedenfalls bei den bei Conrad gelisteten Dioden auch die Wellenlängen runter, und (vermutlich) 5° Verbesserung z.B. beim Vishay TSUS 5202 (950nm) ist zwar einiges, aber ob das reicht? Da klingen 5° beim OSRAM SFH 4555 besser, aber eben dann auf 860nm.
Die Frage wäre, ob nicht das Ausschlachten einer alten FB mehr bringt, sowas sollte noch im Keller zu finden sein und die dortigen Dioden scheinen teilweise bei <4,5V noch bessere Sendeergebnisse zu bringen.

Den Empfänger rückwärts anzuzapfen klingt auch gut. Etwas weitergehend könnte ich ja einfach mal einen Klinkenstecker einstöpseln und sehen, ob es nicht möglich ist, da einen zusätzlichen Empfänger ranzubasteln; Empfangsdiode dürfte ich noch irgenwo eine rumliegen haben, da einen pulldown dran, sofern ich 3-5V+Gnd finde?

Ist aber langsam sehr OT hier, sorry...

Gruß, Beta-User

EDIT: habe jetzt mal einige VISHAY TSAL6200 beim freundlichen Chinesen geordert, das eilt alles ja nicht. Sind mit bis zu 160mA, 17° angegeben; zu vermuten ist, dass auf dem Blaster die "Standard"-Teile mit 20° und 15mA drauf sind. Werde berichten, wird aber dauern.

Auf dem Gateway sind TSAL6400 verbaut. Wieviel Strom sie bekommen habe ich nicht gemessen. Sollte aber deutlich über dem maximal zulässigen liegen, da kein Vorwiderstand eingebaut ist der es begrenzt. Da sie aber immer nur kurz gepulst werden, ist das okay. Bin auf deine Ergebnisse gespannt.
Raspberry Pi 3 | miniCUL 433MHz | nanoCUL 868 MHz | nanoCUL 433 MHz | MySensors WLAN Gateway | LaCrosse WLAN Gateway | SignalESP 433 MHz | SignalESP 868 MHz | HM-MOD-UART WLAN Gateway | IR - 360 Grad WLAN Gateway

Beta-User

Thx für die Info, die TSAL6400 sind auf dem Datenblatt mit 100mA angegeben, das sollte also zwar keinen so großen, aber dennoch spürbaren Unterschied machen.

Jetzt warte ich also erst mal auf die Lieferung, dann sehen wir weiter...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Pfriemler

Ob 5 oder 25 Grad Blickwinkel, ich würde da kaum Unterschied sehen und mir nicht zuviel versprechen. Auch 850 oder 860 nm ... beinahe egal.
Irgendeine Empfangsdiode am Receiver tut es nicht. Die speziellen Empfänger haben i.d.R. sowas wie Bandfilter für die Modulationsfrequenz (im groben - 38 +/- kHz etwa) und geben saubere Flanken weiter. Außerdem ist eine spezielle Eingangsschaltung mit hoher Dynamik verbaut - die Teile reagieren ja wenn man die Fernbedienung an die Wand oder Decke richtet genauso wie wenn man sie aus 10 cm Entfernung "beleuchtet".
In den passend käuflichen Empfängern sind solche Teile i.d.R. auch verbaut.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Beta-User

Zitat von: Beta-User am 26 April 2018, 12:19:41
Senden ist etwas tricky, weil [...] Die Lösung werde ich daher entweder ähnlich machen wie hier, also mit einem Dummy samt zugehörigem MQTT-Bridge-Device (es sei denn Alexander ist mit seiner generischen Bridge schneller):
OpenMQTTGateway - IR, RF, BLE, Temp, Hum + Lux am ESP8266
Habe das zwischenzeitlich umgesetzt, die gesamte Darstellung im Zusammenhang (samt remotecontrol usw.) ist im Wiki zu finden: https://wiki.fhem.de/wiki/IR-MQTT-Gateway.

Fehlt praktisch nur noch die Erhöhung der Sendeleistung...

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

HomeAlone

Hallo zusammen,
ich habe die Platine jetzt hier liegen und wollte mich an den Aufbau machen. Leider muss ich gerade feststellen, dass ich den in der BOM -> https://www.openhardware.io/view/385/MySWeMosIRShield-IR-blaster-shield-for-WeMos-D1#tabs-bom benannten Kondensator C1in 4,7uF  nicht vorrätig habe.  :(

Kann ich diesen auch durch einen anderen substituieren?
Folgende Möglichkeiten (da vorhanden) hätte ich:
a) 4.7uF durch 10uF ersetzten
b) 4.7uF durch 4.7uF /6.3V Tantalum Kondensator ersetzen

Ginge eine dieser beiden Möglichkeiten oder ist davon abzuraten?

Schon einmal vielen Dank im Voraus für Eure Hilfe.

Viele Grüße
Sascha


Pfriemler

Halte beides für unkritisch. Würde a) bevorzugen.

Gesendet von meinem SM-G900FD mit Tapatalk

"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."