ElabNET Technik Forum

danik hat geschrieben: ↑So Mär 21, 2021 6:33 pm Oben haben ich die Timberwolf Lighting Enginge (in der Hoffnung/Annahme dass sich darunter die HUE Ansteuerung befindet)

Ich denke die TIE ist eher ein Logikbaustein um virtuelle Leuchten / Leuchtgruppen zu definieren und denen Befehle zum schalten / dimmen zu übergeben. Diese Befehle wiederum können vorformatiert werden in virtuelle Szenen und Sequenzen.
Mit ein paar Zusatzangaben zu den physikalischen Eigenschaften der Leuchten lassen sich dann auch abgestimmte TW und HCL Steuerungen bauen.

Dabei ist die TIE dann quasi vollkommen virtuell, da am Ende einfach in das Objektsystem die passenden Schalt und Dimmbefehle abgegeben werden. ob dann eine Leuchte per KNX oder DMX an den TWS angeschlossen ist, ist dem TIE egal. HUE wäre dann wohl erstmal eine Ausgabe an MQTT und von dort an einen Adapter (mein Favorit NodeRed).

HUE selbst wäre dann wie Alexa und-Co ein weiteres Protokoll das anzubinden wäre, wobei sich da dann auch die Frage nach HW stellt, denn da gibt es die reinen IP-basierten Befehlssätze an eine andere Bridge als auch in HW eine direkte Anbindung des Funkprotokolls Zigbee, quasi eine Elabnet-Zigbee-Bridge.

Göran, Du hast mich da gerade mit Zigbee-Bridge getriggert...
Grundsätzlich würde ich im aktuellen Stadium keine Ressourcen in irgendwelche eigenen Bridges stecken, wenn es Alternativen am Markt gibt. Ist natürlich die Abwägung, ob man dann die Ressourcen (oder noch mehr) nicht später im Support von Fremdhardware verbraten muss.
Grundsätzlich würde ich an der Stelle aber gerne die Anregung in den Raum werfen, bei Zusatzhardware (auch 1W Busmasterm etc.) statt auf USB-Anbindung in Richtung IP basierter Anbindung zu gehen. Dann lässt sich sowas auch gut dezentral anbinden und eröffnet evtl. auch nen Sekundärmarkt.

Abend zusammen,

ich habe:

• MQTT, um mit meinem Rasenmäher (Gardena mit Robonect) zu kommunizieren (derzeit über OpenHAB)

• UDP/TCP, um mit meinem Hifi-Verstärker zu kommunizieren (derzeit auch über OpenHAB)

Gruß,
Martin

Hallo zusammen,

wenn, dann MQTT vielleicht lässt sich später die CV auf die Schnittstelle umstellen.

MfG Juri

Hallo Miteinander,

MQTT als Broker hauptsächlich für Rasenmäher und über NodeRed für vieles Andere einsetzbar
Zeitschaltuhr einfach und übersichtlich konfigurierbar über eine Zentrale bedienbar

Danke und Gruß

Heiko

Moin moin,

Ich warte dringen auf das DMX Subsystem um mein nur mäßig funktionales KNX-DMX Gateway ( 1 Universum) loszuwerden.
All zu große Ansprüche habe ich dabei gar nicht. Ich würde einzelne Kanäle gerne über die virtuellen Dimmer, als Absolut Wert oder als ein/ausschalt Befehl steuern und hätte gerne von jedem Kanal ein Rückmeldeobjekt wie der aktuelle Wert des Kanals ist.

Als zweites hätte ich gerne eine der zur Auswahl stehenden Maschine2Maschine Protokolle. Ob nun MQTT, Rest-API oder direct TCP/UDP spielt fast keine Rolle. Sobald es eines dieser Protokolle gibt um quasi direkt mit dem Objektsystem des TWS zu kommuniziere lässt sich quasi alles andere darüber auch durch die Community durch z.B. entsprechende Docker realisieren oder man kann durch eigenentwicklung entsprechende Brücken bauen.
KNX (wie bis jetzt) eignet sich dafür meines Erachtens recht wenig.

VG
Earl

Darf ich Fragen wer sich da die WEB-API gewünscht hat und welche Vorteile für nicht-Programmierer das bringt?

Ich wars, weil es eben für mich persönlich die Schnittstelle wäre, die ich selbst direkt ansprechen könnte um anschließend weiterzuverarbeiten.
Wie vorhin aber beschrieben wäre MQTT oder TCP/UDP ebenfalls ok.

VG
Earl

gbglace hat geschrieben: ↑So Mär 21, 2021 9:46 pm Darf ich Fragen wer sich da die WEB-API gewünscht hat und welche Vorteile für nicht-Programmierer das bringt?

Ich wünsch mir auch sowas in der Richtung, oder MQTT oder TCP/UDP.

Als nicht-Programmierer bringt dir das direkt erstmal vermutlich nicht so viel, das bringt dann erst was, wenn jemand beispielsweise ein Modul zur TWS-Anbindung für ein Fremdsystem schreibt (z.B. FHEM, etc.)

Wobei, meine Mobotix Türstation sendet beim Tastendruck TCP-Event-Nachrichten, da braucht man nichts zu programmieren, nur konfigurieren und es wäre schön, wenn der TWS das dann nativ verarbeiten könnte, so wie ich das momentan mit dem Wiregate mache.

Oder die Ladekontrolle meiner Visu um den Akku zu schonen (bei 20% Ladezustand Steckdose an, bei 80% aus). Geht über UDP-Telegramme.

@gbglace Web-API kommt auch von mir. Damit kannst dann Objekte per HTTP Aufruf manipulieren/abfragen. Ein Anwendungsfall wurde vorhin schon genannt, was die Anbindung einer IP-Türstation angeht. Weitere Beispiele (habe ich konkret bei mir):
-Tasmota Devices ohne über MQTT gehen zu müssen (je nach Anwendungsfall)
-Enigma basierte Receiver
-Abfrage vieler Wetterservices (Weatherbit, OpenWeatherMap,...)

Dafür muss man kein Programmierer sein.