Lost in translation - Verwendung externer [IP]-Bridges
-
Hallo zusammen,
anhand meines Status sieht man, ich bin total neuer User - nicht nur im Forum, sondern auch insgesamt mit ioBroker ,-) Eine sehr kurze Zusammenfassung meines Projekts - und auch was meine zentrale Frage als Newbie ist:
Wir wollen (meine Frau meint eher, ich will...) im Rahmen eines großen Renovierungsprojekts eines alten Gutshofs mit mehreren Gebäuden auf Gebäude- und Energieautomatisierung setzen. Wir werden definitiv einen ganzen Zoo aus verschiedenen Geräten und damit auch Protokollen unter einen Hut bringen müssen und als alter IT'ler schrecke ich auch vor selber programmierten und gelöteten Dingen natürlich nicht zurück. Es wird viel Funktechnik zum Einsatz kommen müssen und aufgrund der Entfernung zwischen den Gebäuden werden wir den zentralen ioBroker mit externen Bridges versorgen müssen, die die konkreten Anbindungen übernehmen. Bspw. auch weil die Entfernung zwischen allen Gebäuden inkl. aller Wände einfach zu groß für die normalen "Home-Funktechniken" ist.Ein Beispiel dazu: Schalter A mit EnOcean-Empfänger (und Tastern) steht in Gebäude 1 und der Rechner mit ioBroker steht in Gebäude 2. Alle Gebäude sind per TCP (Ethernet und/oder Wlan) verbunden, also IP-seitig untereinander zu erreichen. Der Empfänger in Gebäude 1 muss also eine Art "EnOcean/IP"-Bridge haben, der irgendwie mit dem zentralen ioBroker kommuniziert. Von diesen Gateways werden wir noch mehrere bekommen, alle versorgen am Ende den ioBroker mit Informationen, einige werden auch im umgekehten Weg Steuersignale versenden.
-
Generelle Frage: Gibt es ein allgemeines Kochrezept bei ioBroker, wie man mit solchen "Technik_X / IP"-Gateways umgeht? So wie ich das verstanden habe, sind die meissten Adapter für eine direkte Integration auf dem Gerät (PC, Server, ...) gedacht, auf dem auch ioBroker selbst läuft - oder ist das falsch gedacht?
Mir ist nicht klar, ob sich die Gateways bspw. per MQTT oder anders mit dem zentralen ioBroker unterhalten - und ob das standardisiert ist? -
Konkret gibt es mit Schaltern von Jung via EnOncean den ersten Anwendungsfall, an dem wir das ausprobieren wollen. Auch hier die Frage, lässt sich der EnOcean-Adapter in diesem Gateway-Modus betreiben oder müsste ggf. für sowas ein lokales ioBroker in dem Gateway betrieben werden?
Ich habe gesehen, dass der User @Jey-Cee sehr fleissig bei dem Thema EnOcean programmiert hat, schonmal super ,-))
Ich bin auch "distributed"-Lösungen dafür sehr offen. Darunter verstehe ich, dass bspw. in jedem Gebäude ein oder mehrere Raspberries mit lokalem ioBroker laufen, jeder direkt hardwareseitig mit den passenden Gatways ausgestattet, und untereinander "irgendwie" vernetzt. Wobei das "irgendwie" wieder meine Frage ist.
Ich bin sicherlich nicht der erste, der mal Komponenten mit mehr als 30m Funkentfernung miteinander verbinden muss, sicherlich gibt es da was - aber im Moment fehlt mir einfach der Einstieg, wo ich schauen muss.
Danke vorab!
Sören@soerenG Wenn du überall Netzwerk bzw. WLan hast dann würden sich Schalter bzw Aktoren per WLan anbieten. Schau dich mal bei Sonoff mit Tasmota oder bei Shelly um was da für dich interessant wäre.
Die Geräte kommunizieren über WLan und landen dann per Adapter oder MQTT im ioBroker. Von dort aus lassen sie sich direkt schalten und zusätzlich mit gewünschten Schaltern verknüpfen.Ich habe beispielsweise bei mir 3 Schalter die lediglich je einen Wemos betätigen. Der Wemos löst dann über den ioBroker den Schaltvorgang am entsprechenden Gerät aus. Einfach weil ich (bzw. meine Holde) an der Stelle einen Schalter wollte und eine Bedienung über Sprach oder Touchsreen nicht gewünscht war. Da ich andererseits keine Lust hatte ewig Kabel zu verlegen habe ich das dann eben so gelöst.
Mit Funklösungen wirst du die von dir beschrieben Reichweiten nicht ganz so einfach zustande bringen.
-
-
Hallo zusammen,
anhand meines Status sieht man, ich bin total neuer User - nicht nur im Forum, sondern auch insgesamt mit ioBroker ,-) Eine sehr kurze Zusammenfassung meines Projekts - und auch was meine zentrale Frage als Newbie ist:
Wir wollen (meine Frau meint eher, ich will...) im Rahmen eines großen Renovierungsprojekts eines alten Gutshofs mit mehreren Gebäuden auf Gebäude- und Energieautomatisierung setzen. Wir werden definitiv einen ganzen Zoo aus verschiedenen Geräten und damit auch Protokollen unter einen Hut bringen müssen und als alter IT'ler schrecke ich auch vor selber programmierten und gelöteten Dingen natürlich nicht zurück. Es wird viel Funktechnik zum Einsatz kommen müssen und aufgrund der Entfernung zwischen den Gebäuden werden wir den zentralen ioBroker mit externen Bridges versorgen müssen, die die konkreten Anbindungen übernehmen. Bspw. auch weil die Entfernung zwischen allen Gebäuden inkl. aller Wände einfach zu groß für die normalen "Home-Funktechniken" ist.Ein Beispiel dazu: Schalter A mit EnOcean-Empfänger (und Tastern) steht in Gebäude 1 und der Rechner mit ioBroker steht in Gebäude 2. Alle Gebäude sind per TCP (Ethernet und/oder Wlan) verbunden, also IP-seitig untereinander zu erreichen. Der Empfänger in Gebäude 1 muss also eine Art "EnOcean/IP"-Bridge haben, der irgendwie mit dem zentralen ioBroker kommuniziert. Von diesen Gateways werden wir noch mehrere bekommen, alle versorgen am Ende den ioBroker mit Informationen, einige werden auch im umgekehten Weg Steuersignale versenden.
-
Generelle Frage: Gibt es ein allgemeines Kochrezept bei ioBroker, wie man mit solchen "Technik_X / IP"-Gateways umgeht? So wie ich das verstanden habe, sind die meissten Adapter für eine direkte Integration auf dem Gerät (PC, Server, ...) gedacht, auf dem auch ioBroker selbst läuft - oder ist das falsch gedacht?
Mir ist nicht klar, ob sich die Gateways bspw. per MQTT oder anders mit dem zentralen ioBroker unterhalten - und ob das standardisiert ist? -
Konkret gibt es mit Schaltern von Jung via EnOncean den ersten Anwendungsfall, an dem wir das ausprobieren wollen. Auch hier die Frage, lässt sich der EnOcean-Adapter in diesem Gateway-Modus betreiben oder müsste ggf. für sowas ein lokales ioBroker in dem Gateway betrieben werden?
Ich habe gesehen, dass der User @Jey-Cee sehr fleissig bei dem Thema EnOcean programmiert hat, schonmal super ,-))
Ich bin auch "distributed"-Lösungen dafür sehr offen. Darunter verstehe ich, dass bspw. in jedem Gebäude ein oder mehrere Raspberries mit lokalem ioBroker laufen, jeder direkt hardwareseitig mit den passenden Gatways ausgestattet, und untereinander "irgendwie" vernetzt. Wobei das "irgendwie" wieder meine Frage ist.
Ich bin sicherlich nicht der erste, der mal Komponenten mit mehr als 30m Funkentfernung miteinander verbinden muss, sicherlich gibt es da was - aber im Moment fehlt mir einfach der Einstieg, wo ich schauen muss.
Danke vorab!
Sören@soerenG Ich habe keinen Gutshof, aber Multi-Host in einem umgebauten Haus ;-)
Bei mir läuft der zentrale ioBroker (noch) als VM auf meinem QNAP NAS und daran sind vier Raspis (3B) als Slaves angehängt und im Haus verteilt. Die Raspis brauche ich vor allem um über I2C über 130 Relais zu schalten. Aber auch USB Schnittstellen wie DMX und IR für Stromzähler sind daran angehängt. Der Master hat keine Hardware dran, aber es laufen darauf über 20 Adapter für Umsysteme und "Cloud" Dienste. Funktioniert alles bestens bis jetzt und kann ich nur empfehlen.
-
-
Hallo zusammen,
anhand meines Status sieht man, ich bin total neuer User - nicht nur im Forum, sondern auch insgesamt mit ioBroker ,-) Eine sehr kurze Zusammenfassung meines Projekts - und auch was meine zentrale Frage als Newbie ist:
Wir wollen (meine Frau meint eher, ich will...) im Rahmen eines großen Renovierungsprojekts eines alten Gutshofs mit mehreren Gebäuden auf Gebäude- und Energieautomatisierung setzen. Wir werden definitiv einen ganzen Zoo aus verschiedenen Geräten und damit auch Protokollen unter einen Hut bringen müssen und als alter IT'ler schrecke ich auch vor selber programmierten und gelöteten Dingen natürlich nicht zurück. Es wird viel Funktechnik zum Einsatz kommen müssen und aufgrund der Entfernung zwischen den Gebäuden werden wir den zentralen ioBroker mit externen Bridges versorgen müssen, die die konkreten Anbindungen übernehmen. Bspw. auch weil die Entfernung zwischen allen Gebäuden inkl. aller Wände einfach zu groß für die normalen "Home-Funktechniken" ist.Ein Beispiel dazu: Schalter A mit EnOcean-Empfänger (und Tastern) steht in Gebäude 1 und der Rechner mit ioBroker steht in Gebäude 2. Alle Gebäude sind per TCP (Ethernet und/oder Wlan) verbunden, also IP-seitig untereinander zu erreichen. Der Empfänger in Gebäude 1 muss also eine Art "EnOcean/IP"-Bridge haben, der irgendwie mit dem zentralen ioBroker kommuniziert. Von diesen Gateways werden wir noch mehrere bekommen, alle versorgen am Ende den ioBroker mit Informationen, einige werden auch im umgekehten Weg Steuersignale versenden.
-
Generelle Frage: Gibt es ein allgemeines Kochrezept bei ioBroker, wie man mit solchen "Technik_X / IP"-Gateways umgeht? So wie ich das verstanden habe, sind die meissten Adapter für eine direkte Integration auf dem Gerät (PC, Server, ...) gedacht, auf dem auch ioBroker selbst läuft - oder ist das falsch gedacht?
Mir ist nicht klar, ob sich die Gateways bspw. per MQTT oder anders mit dem zentralen ioBroker unterhalten - und ob das standardisiert ist? -
Konkret gibt es mit Schaltern von Jung via EnOncean den ersten Anwendungsfall, an dem wir das ausprobieren wollen. Auch hier die Frage, lässt sich der EnOcean-Adapter in diesem Gateway-Modus betreiben oder müsste ggf. für sowas ein lokales ioBroker in dem Gateway betrieben werden?
Ich habe gesehen, dass der User @Jey-Cee sehr fleissig bei dem Thema EnOcean programmiert hat, schonmal super ,-))
Ich bin auch "distributed"-Lösungen dafür sehr offen. Darunter verstehe ich, dass bspw. in jedem Gebäude ein oder mehrere Raspberries mit lokalem ioBroker laufen, jeder direkt hardwareseitig mit den passenden Gatways ausgestattet, und untereinander "irgendwie" vernetzt. Wobei das "irgendwie" wieder meine Frage ist.
Ich bin sicherlich nicht der erste, der mal Komponenten mit mehr als 30m Funkentfernung miteinander verbinden muss, sicherlich gibt es da was - aber im Moment fehlt mir einfach der Einstieg, wo ich schauen muss.
Danke vorab!
SörenIch habe jetzt mehrfach deinen Beitrag gelesen und glaube du hast das mit den Adaptern nicht richtig verstanden.
Die Adapter laufen nicht Standalone und es gibt keinen Gateway modus.@soerenG sagte in Lost in translation - Verwendung externer [IP]-Bridges:
So wie ich das verstanden habe, sind die meissten Adapter für eine direkte Integration auf dem Gerät (PC, Server, ...) gedacht, auf dem auch ioBroker selbst läuft - oder ist das falsch gedacht?
Eigentlich gibt es nur Z-Wave, Zigbee und EnOcean die direkt in ioBroker integriert sind. Die meissten anderen Adapter Kommunizieren über das Netzwerk mit ihrem Gegenüber (Gateway oder Dienst).
@soerenG sagte in Lost in translation - Verwendung externer [IP]-Bridges:
Mir ist nicht klar, ob sich die Gateways bspw. per MQTT oder anders mit dem zentralen ioBroker unterhalten - und ob das standardisiert ist?
Das hängt immer vom jeweiligen Gateway ab und was es kann bzw. welche Schnittstellen es zur verfügung stellt.
@soerenG sagte in Lost in translation - Verwendung externer [IP]-Bridges:
lässt sich der EnOcean-Adapter in diesem Gateway-Modus betreiben
Nein, der Adapter nutzt einen USB-Stick und kein Gateway. Hier ist auf jedenfall Multihost nötig.
Persönlicher Support
Spenden -> paypal.me/J3YC33 -
-
Ich habe jetzt mehrfach deinen Beitrag gelesen und glaube du hast das mit den Adaptern nicht richtig verstanden.
Die Adapter laufen nicht Standalone und es gibt keinen Gateway modus.@soerenG sagte in Lost in translation - Verwendung externer [IP]-Bridges:
So wie ich das verstanden habe, sind die meissten Adapter für eine direkte Integration auf dem Gerät (PC, Server, ...) gedacht, auf dem auch ioBroker selbst läuft - oder ist das falsch gedacht?
Eigentlich gibt es nur Z-Wave, Zigbee und EnOcean die direkt in ioBroker integriert sind. Die meissten anderen Adapter Kommunizieren über das Netzwerk mit ihrem Gegenüber (Gateway oder Dienst).
@soerenG sagte in Lost in translation - Verwendung externer [IP]-Bridges:
Mir ist nicht klar, ob sich die Gateways bspw. per MQTT oder anders mit dem zentralen ioBroker unterhalten - und ob das standardisiert ist?
Das hängt immer vom jeweiligen Gateway ab und was es kann bzw. welche Schnittstellen es zur verfügung stellt.
@soerenG sagte in Lost in translation - Verwendung externer [IP]-Bridges:
lässt sich der EnOcean-Adapter in diesem Gateway-Modus betreiben
Nein, der Adapter nutzt einen USB-Stick und kein Gateway. Hier ist auf jedenfall Multihost nötig.
@Jey-Cee sagte in Lost in translation - Verwendung externer [IP]-Bridges:
Nein, der Adapter nutzt einen USB-Stick und kein Gateway. Hier ist auf jedenfall Multihost nötig.
Eine Möglichkeit wäre ggf. die serielle Schnittstelle mit
usbipüber's Netzwerk zu teilen, wenn man keinen ioBroker auf dem anderen Host haben will.Alternativ (mit einer kleinen Anpassung) können Adapter, die seriell sprechen, auch via
ser2netgehostete serielle Schnittstellen ansprechen. Der Aufwand im Code beläuft sich auf Serialport-Instanz durch TCP-Socket ersetzen. -
@soerenG sagte in Lost in translation - Verwendung externer [IP]-Bridges:
Darunter verstehe ich, dass bspw. in jedem Gebäude ein oder mehrere Raspberries mit lokalem ioBroker laufen, jeder direkt hardwareseitig mit den passenden Gatways ausgestattet, und untereinander "irgendwie" vernetzt. Wobei das "irgendwie" wieder meine Frage ist.
Was du suchst ist Multihost:
https://www.iobroker.net/#de/documentation/config/multihost.mdHierbei fungiert ein ioBroker als Master und alle anderen kommunizieren mit diesem.
@AlCalzone said in Lost in translation - Verwendung externer [IP]-Bridges:
@soerenG sagte in Lost in translation - Verwendung externer [IP]-Bridges:
Darunter verstehe ich, dass bspw. in jedem Gebäude ein oder mehrere Raspberries mit lokalem ioBroker laufen, jeder direkt hardwareseitig mit den passenden Gatways ausgestattet, und untereinander "irgendwie" vernetzt. Wobei das "irgendwie" wieder meine Frage ist.
Was du suchst ist Multihost:
https://www.iobroker.net/#de/documentation/config/multihost.mdHierbei fungiert ein ioBroker als Master und alle anderen kommunizieren mit diesem.
Aha, hört sich gut an
Ich habe grade mal auf die man page geschaut, das mit dem "Multihost" wurde ja jetzt 3x gepostet, sieht gut aus. Werde mir mal die nächsten Tage 3 Raspberries zum rumspielen holen und das testweise aufbauen bevor ich das auf den Elektriker loslasse ,-)@Jey-Cee : Ich glaube ich weiss jetzt auch, was Du meinst - Also "Multihost" ist wohl die Lösung.
@Chaot : Über die Shelly-Familie bin ich auch bereits gestolpert, das ist bei uns bereits gesetzt, dass praktisch alle Aktoren wie Licht, Lüftung, LED usw. sich mit shellys angesteuert werden. Ich will mal testweise einen mit tasmota flashen um zu sehen, ob das einen Unterschied macht, aber shelly hat ja wohl die Cloud nur optional in der Original-FW, also vermutlich klappt das dann auch so.
Also vielen Dank für die Hilfe an Euch, ich probiere mal einen Testaufbau und schaue mir an, wie das läuft.
Grüße,
Sören -
@AlCalzone said in Lost in translation - Verwendung externer [IP]-Bridges:
@soerenG sagte in Lost in translation - Verwendung externer [IP]-Bridges:
Darunter verstehe ich, dass bspw. in jedem Gebäude ein oder mehrere Raspberries mit lokalem ioBroker laufen, jeder direkt hardwareseitig mit den passenden Gatways ausgestattet, und untereinander "irgendwie" vernetzt. Wobei das "irgendwie" wieder meine Frage ist.
Was du suchst ist Multihost:
https://www.iobroker.net/#de/documentation/config/multihost.mdHierbei fungiert ein ioBroker als Master und alle anderen kommunizieren mit diesem.
Aha, hört sich gut an
Ich habe grade mal auf die man page geschaut, das mit dem "Multihost" wurde ja jetzt 3x gepostet, sieht gut aus. Werde mir mal die nächsten Tage 3 Raspberries zum rumspielen holen und das testweise aufbauen bevor ich das auf den Elektriker loslasse ,-)@Jey-Cee : Ich glaube ich weiss jetzt auch, was Du meinst - Also "Multihost" ist wohl die Lösung.
@Chaot : Über die Shelly-Familie bin ich auch bereits gestolpert, das ist bei uns bereits gesetzt, dass praktisch alle Aktoren wie Licht, Lüftung, LED usw. sich mit shellys angesteuert werden. Ich will mal testweise einen mit tasmota flashen um zu sehen, ob das einen Unterschied macht, aber shelly hat ja wohl die Cloud nur optional in der Original-FW, also vermutlich klappt das dann auch so.
Also vielen Dank für die Hilfe an Euch, ich probiere mal einen Testaufbau und schaue mir an, wie das läuft.
Grüße,
Sören@soerenG Bei den Shellys musst du aufpassen wenn du elektronische Trafos für LEDs schalten willst. Die reißen das Relais kaputt weil sie zu viel Spitzenstrom ziehen. Wenn du mit LEDs arbeitest würde ich normale Trafos empfehlen oder Hochvolt LEDs.
Ich persönlich verwende lieber Tasmota weil ich dort viele Geräte unter einem Adapter unterbringen kann bei dem die Struktur immer gleich ist.
Also laufen meine Sensoren die an Wemos D1 Mini hängen und überall verteilt sind genauso auf den Sonoff Adapter wie die genutzen Schalter.
Könnte man zwar auch alles über den MQTT Adapter machen, aber ich finde den Sonoff etwas bequemer zu bedienen.Wobei das wirklich nur persönliche Vorlieben sind. Der ioBroker kommt mit dem Shelly- und dem Sonoff Adapter auch problemlos gleichzeitig zurecht.
Noch ein Hinweis: Vergiss nicht für Sensorik eine Verkabelung oder Platzierung vorzusehen.
Ich habe bei meiner Wohnung in der FB-Leiste ringsum eine Leitung mit 5V liegen. Davon kann ich problemlos schnell mal einen Wemos abzapfen ohne überall Steckernetzteile zu benötigen. Teilweise verschwinden die Wemos dann sogar auch hinter den Sockelleisten. Wenn du jetzt in der Planungsphase schon einkalkulierst wo du eventuell Wettersensoren, Kameras und Dekolampen anbringen möchtest sparst du dir hinterher viel Arbeit. Klar gehen Kameras auch per WLan, aber sie brauchen trotzdem eine Stromversorgung. -
@soerenG Bei den Shellys musst du aufpassen wenn du elektronische Trafos für LEDs schalten willst. Die reißen das Relais kaputt weil sie zu viel Spitzenstrom ziehen. Wenn du mit LEDs arbeitest würde ich normale Trafos empfehlen oder Hochvolt LEDs.
Ich persönlich verwende lieber Tasmota weil ich dort viele Geräte unter einem Adapter unterbringen kann bei dem die Struktur immer gleich ist.
Also laufen meine Sensoren die an Wemos D1 Mini hängen und überall verteilt sind genauso auf den Sonoff Adapter wie die genutzen Schalter.
Könnte man zwar auch alles über den MQTT Adapter machen, aber ich finde den Sonoff etwas bequemer zu bedienen.Wobei das wirklich nur persönliche Vorlieben sind. Der ioBroker kommt mit dem Shelly- und dem Sonoff Adapter auch problemlos gleichzeitig zurecht.
Noch ein Hinweis: Vergiss nicht für Sensorik eine Verkabelung oder Platzierung vorzusehen.
Ich habe bei meiner Wohnung in der FB-Leiste ringsum eine Leitung mit 5V liegen. Davon kann ich problemlos schnell mal einen Wemos abzapfen ohne überall Steckernetzteile zu benötigen. Teilweise verschwinden die Wemos dann sogar auch hinter den Sockelleisten. Wenn du jetzt in der Planungsphase schon einkalkulierst wo du eventuell Wettersensoren, Kameras und Dekolampen anbringen möchtest sparst du dir hinterher viel Arbeit. Klar gehen Kameras auch per WLan, aber sie brauchen trotzdem eine Stromversorgung.Hallo @Chaot, danke für den Tip mit den LEDs. Das Problem ist leidlich bekannt, bei uns werden aber wohl nur Hochvolt LEDs sowie Stripes mit dem Shelly LED-Treiber direkt angesprochen.
Hast Du es mal mit dem eQ-3 Einschalt-Strombegrenzer probiert? Alternativ kann mann statt einem NTC wohl auch einen Snubber basteln (siehe hier: http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.25.1), bisserl Draht + R + C, fertig. Aber in der Detailstufe sind wir noch nicht in der Planung angekommen ;-)Edit: Jetzt hast Du mich neugierig gemacht...habe eben bei Aliexpress nachgeschaut, da gibt es schicke fertige snubber-Schaltungen für 50 ct/Stück, da lohnt sich das selbermachen nicht mehr. Muss man nur noch für die jeweilige Leistung das passende Model finden.
PS: Das Problem taucht übrigens auch bei Hochvolt LEDs auf, denn die haben ja quasi ein eingebautes VSG. -
Hallo @Chaot, danke für den Tip mit den LEDs. Das Problem ist leidlich bekannt, bei uns werden aber wohl nur Hochvolt LEDs sowie Stripes mit dem Shelly LED-Treiber direkt angesprochen.
Hast Du es mal mit dem eQ-3 Einschalt-Strombegrenzer probiert? Alternativ kann mann statt einem NTC wohl auch einen Snubber basteln (siehe hier: http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.25.1), bisserl Draht + R + C, fertig. Aber in der Detailstufe sind wir noch nicht in der Planung angekommen ;-)Edit: Jetzt hast Du mich neugierig gemacht...habe eben bei Aliexpress nachgeschaut, da gibt es schicke fertige snubber-Schaltungen für 50 ct/Stück, da lohnt sich das selbermachen nicht mehr. Muss man nur noch für die jeweilige Leistung das passende Model finden.
PS: Das Problem taucht übrigens auch bei Hochvolt LEDs auf, denn die haben ja quasi ein eingebautes VSG.@soerenG Bezüglich LED habe ich mich für 24V und eine zentrale Versorgung entschieden: 2 riesige Meanwell Netzteile und dahinter jeden Kanal mit DMX gesteuert (2x 12-fach DMX Decoder). Aber die Frage ist, ob eine zentrale Lösung bei dir in Frage kommt. Dasselbe bei den Relais: ich habe alle Drähte an zwei Orten zusammen gezogen und dort all meine Relais verbaut.
Ich bin kein Freund von Funk (und damit WLAN), aber ich weiss, dass das in einem Umbau manchmal die einzige Lösung ist (habe 4x Funk Loxone und etliche Homamatic Funk Sensoren und Aktoren).
-
Hallo @Chaot, danke für den Tip mit den LEDs. Das Problem ist leidlich bekannt, bei uns werden aber wohl nur Hochvolt LEDs sowie Stripes mit dem Shelly LED-Treiber direkt angesprochen.
Hast Du es mal mit dem eQ-3 Einschalt-Strombegrenzer probiert? Alternativ kann mann statt einem NTC wohl auch einen Snubber basteln (siehe hier: http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.25.1), bisserl Draht + R + C, fertig. Aber in der Detailstufe sind wir noch nicht in der Planung angekommen ;-)Edit: Jetzt hast Du mich neugierig gemacht...habe eben bei Aliexpress nachgeschaut, da gibt es schicke fertige snubber-Schaltungen für 50 ct/Stück, da lohnt sich das selbermachen nicht mehr. Muss man nur noch für die jeweilige Leistung das passende Model finden.
PS: Das Problem taucht übrigens auch bei Hochvolt LEDs auf, denn die haben ja quasi ein eingebautes VSG. -
@soerenG Bezüglich LED habe ich mich für 24V und eine zentrale Versorgung entschieden: 2 riesige Meanwell Netzteile und dahinter jeden Kanal mit DMX gesteuert (2x 12-fach DMX Decoder). Aber die Frage ist, ob eine zentrale Lösung bei dir in Frage kommt. Dasselbe bei den Relais: ich habe alle Drähte an zwei Orten zusammen gezogen und dort all meine Relais verbaut.
Ich bin kein Freund von Funk (und damit WLAN), aber ich weiss, dass das in einem Umbau manchmal die einzige Lösung ist (habe 4x Funk Loxone und etliche Homamatic Funk Sensoren und Aktoren).
@UncleSam Das Thema geht zwar ein bischen OT, aber Du stelltest ja eine Frage ,-) Ich programmiere und löte jetzt seit rund 40 Jahren - und habe in dieser Zeit schon ziemlich viele Techniken kommen und gehen sehen. Dadurch bin ich inzwischen eher konservativ geworden, wenn es gilt, bestimmte Techniken auszuwählen, denn erfahrungsgemäß wird es in 10~15 Jahren keine Ersatzteile dazu mehr geben und in 25 Jahren ist ein Komplettaustausch notwendig. Pesönlich glaube ich, dass die Techniklebensdauer von Heimautomatisierung und die Lebensdauer von Häuser nur schwer in Einklang zu bringen sind und die Systeme von Anfang an so gebaut werden müssen, dass der Technik-Teil problemlos austauschbar ist. Das ist eine Illusion: Alleine dem Installteuer zu erklären, was ich jetzt grade an Technik haben will, ist eine Herausforderung ,-) Beim Thema Austauschbarkeit in 20 Jahren fange ich gar nicht erst an, da wird bei uns nicht diskutiert sondern er kriegt einfach Vorgaben, was zu tun ist, basta.
Also werden alle Leuchten klassisch mit 220V/Retrofit und einfach via Aktor - einzeln oder in Gruppen - angesteuert. Diese sitzen zugänglich in kleinen Unterputzdosen, Wartung jederzeit möglich. Beim Thema Funk bin ich auch zwiegespalten. Natürlich spart man reichlich Kabelaufwand damit, ist super-flexibel. Und wenn in 20 Jahren ein neuer, besserer Funkstandard exisitiert, werde ich die Aktoren + Sender austauschen gut ist. Jetzt muss ich halt damit Leben, dass wir noch mehr Funk zu Hause haben, aber davon ist man halt heutzutage umgeben, so ist das.
Auf das letzte Quentchen Komfort und Rafiniertheit, wie DMX (Hut ab, sicherlich ziemlich aufwendig!) muss man dann halt verzichten, aber da ich bin inzwischen auch mit weniger zufrieden ,-) -
@UncleSam Das Thema geht zwar ein bischen OT, aber Du stelltest ja eine Frage ,-) Ich programmiere und löte jetzt seit rund 40 Jahren - und habe in dieser Zeit schon ziemlich viele Techniken kommen und gehen sehen. Dadurch bin ich inzwischen eher konservativ geworden, wenn es gilt, bestimmte Techniken auszuwählen, denn erfahrungsgemäß wird es in 10~15 Jahren keine Ersatzteile dazu mehr geben und in 25 Jahren ist ein Komplettaustausch notwendig. Pesönlich glaube ich, dass die Techniklebensdauer von Heimautomatisierung und die Lebensdauer von Häuser nur schwer in Einklang zu bringen sind und die Systeme von Anfang an so gebaut werden müssen, dass der Technik-Teil problemlos austauschbar ist. Das ist eine Illusion: Alleine dem Installteuer zu erklären, was ich jetzt grade an Technik haben will, ist eine Herausforderung ,-) Beim Thema Austauschbarkeit in 20 Jahren fange ich gar nicht erst an, da wird bei uns nicht diskutiert sondern er kriegt einfach Vorgaben, was zu tun ist, basta.
Also werden alle Leuchten klassisch mit 220V/Retrofit und einfach via Aktor - einzeln oder in Gruppen - angesteuert. Diese sitzen zugänglich in kleinen Unterputzdosen, Wartung jederzeit möglich. Beim Thema Funk bin ich auch zwiegespalten. Natürlich spart man reichlich Kabelaufwand damit, ist super-flexibel. Und wenn in 20 Jahren ein neuer, besserer Funkstandard exisitiert, werde ich die Aktoren + Sender austauschen gut ist. Jetzt muss ich halt damit Leben, dass wir noch mehr Funk zu Hause haben, aber davon ist man halt heutzutage umgeben, so ist das.
Auf das letzte Quentchen Komfort und Rafiniertheit, wie DMX (Hut ab, sicherlich ziemlich aufwendig!) muss man dann halt verzichten, aber da ich bin inzwischen auch mit weniger zufrieden ,-)@soerenG sagte in Lost in translation - Verwendung externer [IP]-Bridges:
DMX (Hut ab, sicherlich ziemlich aufwendig!)
Nein, da habe ich mir das Leben einfach gemacht: über meinen uDMX Adapter kann ich per USB die beiden LED Steuergeräte ansteuern - zudem habe ich noch einige 230V Dimmer dran. Es gibt keine DMX Steuerung, keine Universen, etc.
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden464
Online32.9k
Benutzer83.0k
Themen1.3m
Beiträge