KNX per UDP an den MS Go

[AlexAn]

KNX IP Gateway erforderlich z.B.:
MDT SCN-IP000.03 IP Interface ca. 150Euro

https://www.mdt.de/IP_Interface_Router.html

NodeRed einmalig als Gateway einrichten für die Umleitung auf UDP
https://www.loxwiki.eu/pages/viewpag...ageId=18219468

https://flows.nodered.org/node/node-red-contrib-knx

Flow:

[
{
"id": "731808b0.7cc9b8",
"type": "tab",
"label": "KNX",
"disabled": false,
"info": ""
},
{
"id": "8c604e11.05dae",
"type": "knx-in",
"z": "731808b0.7cc9b8",
"name": "",
"controller": "a3679c7d.e8ed3",
"x": 450,
"y": 160,
"wires": [
[
"8fecc67a.4a9bf8"
]
]
},
{
"id": "3f619580.f3f7aa",
"type": "udp out",
"z": "731808b0.7cc9b8",
"name": "",
"addr": "10.0.0.20",
"iface": "",
"port": "9111",
"ipv": "udp4",
"outport": "",
"base64": false,
"multicast": "false",
"x": 880,
"y": 160,
"wires": []
},
{
"id": "8fecc67a.4a9bf8",
"type": "json",
"z": "731808b0.7cc9b8",
"name": "",
"property": "payload",
"action": "",
"pretty": false,
"x": 630,
"y": 160,
"wires": [
[
"3f619580.f3f7aa"
]
]
},
{
"id": "e8aa9cb0.6683b",
"type": "udp in",
"z": "731808b0.7cc9b8",
"name": "",
"iface": "",
"port": "9222",
"ipv": "udp4",
"multicast": "false",
"group": "",
"datatype": "utf8",
"x": 460,
"y": 260,
"wires": [
[
"b02f3daf.227ab"
]
]
},
{
"id": "b02f3daf.227ab",
"type": "knx-out",
"z": "731808b0.7cc9b8",
"name": "",
"controller": "a3679c7d.e8ed3",
"x": 890,
"y": 260,
"wires": []
},
{
"id": "a3679c7d.e8ed3",
"type": "knx-controller",
"z": "",
"name": "MDT IP Interface",
"host": "10.0.0.41",
"port": "3671",
"mode": "tunnel/unicast"
}
]

Config:


Bei den Vorlagen noch die Adressen,IP und Port ausbessern:


Nicht vergessen die Vorlagen von .txt auf .xml abändern zum Importieren!
image_24118.txt
image_24119.txt

[cRieder]

Top

Damit kann man KNX natürlich auch in den Gen2 bringen.

[BSiege]

100 Punkte!!!
Genau in diese Richtung gingen meine Überlegungen. Noch bevor ich mir eigene Ideen zusammengoogeln konnte, ist schon eine mögliche Lösung da. Vielen, vielen Dank! Dass es seit zwei Jahren node-red-contrib-knx gibt, ist an mir vorbeigegangen. Da war auch noch weniger Leidensdruck. Meine Taktik ist grundsätzlich meine Loxone Installation über die Runden zu bringen und meine original-Beweggründe für diesen Systementscheid zu retten. Meine Glastaster werden den Miniserver um ein vielfaches Überleben, das war schon zum Start klar.

Jetzt ist nur die Frage, wie gut Gen1 mit dem zusätzlichen UDP-Aufwand klar kommt. Aber das kann man zumindest problemlos Simulieren. Sogar parallel zum bestehenden Betrieb.

[cRieder]

Und der Gen2 kommt sicher besser mit erhöhter UDP-Last zurecht

[AlexAn]

Anbei der Monitor von meinem Go den ich laut Config mit 33% ausgelastet habe:
Ca. 280 Adressen

[svethi]

Das konnte eigentlich nur die richtige Antwort auf das KNX Modul sein.

[AlexAn]

Hab neue Vorlagen oben eingefügt:


Eingänge

Port wie im NodeRed Gateway für den Eingang verwenden



Adresse wie in der ETS einsetzen




Ausgänge:

IP vom Loxberry und Port vom NodeRed Gateway einsetzen



Adresse wie in der ETS einsetzen


Wollte eigentlich Gruppen machen um besser zu sortieren aber beim Eingangsport 9111 schreit jetzt die Config dass der Port schon verwendet wurde!

Wer testen möchte bitte um kurze Rückmeldung ob alles OK ist dann schreib ich das Wiki dazu!!

[zains]

Hallo, die aktuelle Konfiguration des virtuellen KNX-Ausgangs verfügt nur über EIN/AUS-Befehle. Ich möchte eine Dimmsteuerung implementieren und muss eine 1-Byte-Helligkeitswertsteuerung verwenden. Wie soll ich die Parameter einstellen?

[hismastersvoice]

Jetzt ist nur die Frage, wie gut Gen1 mit dem zusätzlichen UDP-Aufwand klar kommt. Aber das kann man zumindest problemlos Simulieren. Sogar parallel zum bestehenden Betrieb.

UDP erzeugt sehr wenig Traffic, aber die Auswertung braucht halt Rechenleistung.
Die Frage könnte sein ob man nicht lieber gleich entsprechende VIs schaltet, das wäre im normalen Programmablauf sicher etwas Ressourcen schonender.

Allerdings darf man eines nicht vergessen, es ist halt wieder basteln.
Das passt sicher für den ein oder anderen hier, aber die Dokumentation muss sauber gemacht werden. Sonst findet sich da nie weider jemand rein.
Ich stelle immer mehr fest das zwar die alternativen Geräte und Lösungen günstig und auch gut sind, aber ich auch Stunden mit der Dokumentation verbringe.

[hismastersvoice]

PS: Das schreit doch gerade zu nach einem Loxberry Plugin.

[AlexAn]

Stimmt im ersten Schritt aber im 2.Schritt bräuchten wir Hardware ala pmayer

[pmayer]

Warum eigentlich udp und nicht node-red-contrib-loxone? Da läuft die komplette Kommunikation über _einen_ geöffneten Websocket.

Bzgl. Hardware: Grundliegend bin ich bei sowas immer dabei. Aber ich glaube dass sowas nicht für einen Preis vom unterhalb eines KNX/IP-Gateways liegt. Und, ich habe gerade gar keine Ahnung wie ich KNX sprechen könnte... vom Protokoll her sollte es zumindest einfach sein, oder?

[AlexAn]

Hatte das mit node-red-contrib-loxone im Fokus aber letztlich wollte ich alles in der Config machen.

[pmayer]

Ahso. Dachte, da du sowieso node-red nutzt... finde es halt umständlich für alles einen virtuellen Eingang/Ausgang zu machen, wenn du mit node-red-contrib-loxone direkt an die controls kannst.

Aber genau genommen völlig Wurst. so lange es funktioniert :-)

[hismastersvoice]

Nur mal so als Ansatz...
Bei Weinzierl gibt es sehr gute KNX Produkte, mit einer genau so guten SDK.

Direkt auf einen Rapberry
https://www.weinzierl.de/index.php/de/alles-knx1/knx-module/knx-baos-modul-838

oder als LAN-Schnittstelle

https://www.weinzierl.de/index.php/de/alles-knx1/knx-devices/knx-ip-interface-731-de

SDK
http://weinzierl-engineering.github.io/baos/cpp_api/index.html

Für den Raspberry gibt es ein kDriveExpress bei dem auch ein paar PYthon und C++ Beispiel dabei sind.

Leider bin ich ja so gar kein KNXler und habe deswegen auch keine Hardware um das zu testen.
Aber vielleicht wäre das ein Ansatz um eine gute KNX<->Loxone Schnittstelle zu bauen. Man könnte vielleicht sogar über Logik eine es solchen Programm ein paar Probleme beheben die hier manche habe mit zB Shading-Aktoren haben etc.

[AlexAn]

Die FHEM Jungs haben da schon gebastelt dran: https://forum.fhem.de/index.php?topic=60397.0
Hätte einen Test Raspberry 4 und das Diagnose Netzteil.
Denke ich hol mir mal das Teil zum Spielen mit https://www.loxwiki.eu/display/LOXBERRY/KNXd

[svethi]

Hast kein Pi3? Obwohl, es ist Winter, da wird man die Abwärme besser los 😂

[svethi]

Ich würde eine Lösung ohne FHEM aber vorziehen

[AlexAn]

svethi hängt zwar noch frei rum aber mit dem Lüfter geht´s


mein MDT IP redet schon mal mit mir per KNXd Plugin am Loxberry 2.0.0.3:

[svethi]

Ich sag ja, im Winter gehts :-)

[svethi]

Es kann aber schon sein, dass das eine gewisse Logik rein muss. Bei den EIB Bausteinen ist das so, dass eine Statusänderung am Statuseingang auch auf den Ausgang durchgereicht wird. Kommt diese Änderung allerdings durch den Statuseingang, wird sie durch den KNX-Verbinder nicht auf den Bus übertragen. Ich hätte diese Logik eher im Baustein vermutet, aber Loxone macht das irgendwie zwischendrin. Das müsst auf alle Fälle dann auch "behandelt" werden.

[pmayer]

Ach jetzt hab ichs verstanden. Das Ganze "ohne" node-red direkt per UDP auf KNX machen.

Bin bei hismastersvoice und svethi. Im Vergleich zu den Lösungen mit KNX/IP-Gateway lohnt sich glaube keine Neuentwicklung. Dazu kommt noch, dass man - wie schon gesagt - evtl. Logik abbilden muss. Durch Möglichkeiten wie LoxBerry und node-red hat man da glaube die besseren Chancen.

[Labmaster]

Das ist ja alles ganz "net", aber ich für meinen Teil werde sicher keinerlei IP Kommunikation zur Laufzeit in systemkritischen Bereiche (Licht, Beschattung, Heizung) einsetzen.
Wie ich schon öffter mal geschrieben habe, ein Haus ist ein Haus und kein Smartphone. Im besten Fall müßen systemkritischen Komponennten auch mal 10 bis 30 Jahre unauffällig ohne Wartung, Updates oder wieteres Zutun ... auskommen.
Aus Erfahrung meiner ersten Eigenbau "Smarthome" Installation von vor über 25 Jahren weis ich wie schnell sich Interessen und Zeitkontigente verändern können. Irgendwann willst du nur noch Ruhe habe und das es funktioniert.
Wenn mal das Netzwerk abkackt, dann geht halt mal für ein paar Stunden der TV das Radio und die IT nicht mher, aber wenigstens soll es Warm/Kalt bleiben und ich nicht mit Kerzen rumhantieren müßen.

[hismastersvoice]

Wenn mal das Netzwerk abkackt, dann geht halt mal für ein paar Stunden der TV das Radio und die IT nicht mher, aber wenigstens soll es Warm/Kalt bleiben und ich nicht mit Kerzen rumhantieren müßen.

Stimme ich dir nur bedingt zu. Denn wenn der MS oder die KNX-Ext abkackt ist es ja genau so kalt und dunkel.
Aber das ist Ansichtssache

Das einzige was ich nicht mehr mache und inzwischen kpl. umgebaut habe ist das kein Sensor mehr übers WLAN läuft.
Immer wieder gab es trotz gutem WLAN immer wieder Probleme.
Inzwischen laufen einige Sensoren zB CO² oder RFID etc. / Anwesenheit-Erkennung übers LAN, und machen keine Probleme.

Meist ist es nicht so das mich der Preis stört, es sind oft einfach Dinge die mich an den Geräten selber stören.
Dann bleibt ganz oft nur die Umsetzung mit eigenen mitteln.

[pmayer]

Hey Labmaster,

ich verstehe deinen Punkt völlig, sehe ihn aber bezüglich Netzwerk etwas anders. Eine funktionierende Automation hängt an einer funktionierenden Infrastruktur. Ich meine mich aber zu erinnern, dass genau das auch immer das Argument der KNX-Leute gegen Loxone ist: "Wenn da mal die Zentrale (Miniserver) ausfällt... meine KNX-Geräte kommunizieren direkt miteinander!"
Ob man jetzt aber IP oder irgend etwas anderes (KNX, RS485, LoxBus, CAN, DMX, etc.) zur Kommunikation/Steuerung im Eigenheim nutzt ist meiner Meinung nach völlig sekundär. Fällt diese "Grundlage" aus, hat man ein Problem.

Man sollte also seine Kommunikationsinfrastruktur so ausfallsicher wie möglich aufbauen - egal bei welcher. Beim Miniserver hängt man zur Not einen zweiten als Fall-Back da hin. Netzwerke separiert man und lässt diese entweder auf leicht austauschbarer Hardware mit Backup laufen oder baut einen HA-Betrieb.
Dazu gehört dann auch, dass das WLan bzw. das komplette Netz, über das man vielleicht etwas schaltet, eben nicht mit dem Billo-Router vom Provider gebaut ist sondern eben mit ordentlicher Hardware mit ordentlichen Switchen. Zusätzlich dazu am besten noch mit Überwachung der Systeme und Dienste um auf Ausfälle schnell reagieren zu können.

Als Beispiel: Jeder erzählt mir immer, man solle feste IP's für die Automation nehmen. Ich nutze komplett DNS-basierte Namensauflösung und jedes Gerät bekommt per DHCP seine IP's. In einem Netz in dem man auch IPV6 fährt, tippt man keine Adressen mehr per Hand. Ergo muss ich mich drum kümmern, dass mein DHCP-Server läuft...
Meine Automation (Dimmer, Aktorik, Sensorik) ist alles per Netzwerk angebunden und hängt an einem ordentlichen Switch - keine Loxone. Das IoT Netz bekommt bei Zeiten ein eigenes VLAN, was ich im besten Fall über einen eigenen, leicht austauschbaren Switch, laufen lasse. USV habe ich noch keine, gehört aber eventuell auch in so ein Setup.

Jeder Kommunikation erzeugt also Abhängigkeiten die es gilt - je nach Wichtigkeit der Systeme - abzusichern und ausfallsicher zu betreiben.

Ich komme eben aus der IT und ganz früher aus der Elektroinstallation. Da fällt es mir sicher leichter mit diesen IT-Grundlagen umzugehen, wie aber oben geschrieben gilt das für jede wichtige Kommunikationsinfrastruktur.
Bitte nicht falsch verstehen. Ich teile deine Sorge und in manchen Fällen macht es Sinn, Systeme zu separieren und Autark laufen zu lassen.

Gruß,
p

[hismastersvoice]

Was für mich auch dazu gehört...
Im Schrank habe ich Schalter für die Hutschiene, in meinem Fall von ABB. Diese Sind für die wichtigsten Lichter, EDV, und Heizung (icl. Stellantriebe).
Fällt wirklich mal etwas größeres aus, was ich nicht sofort beheben kann, bleibt mir immer noch die Möglichkeit das ganze von Hand zu schalten.
Ersatzteile wie Netzteile, Switch und auch ein MiniServer gehören für mich einfach auf Reserve in den Schrank oder Schublade..

[Labmaster]

Wenn man ein reines IP Netzwerk für sich nur zwischen Miniserver und Gateway hätte (also nur ein Kabel), dann wäre die Sache sicher etwas abgemildert aber leider hat der Miniserver nur ein Netzwerkinterface für alles.

Ob man jetzt aber IP oder irgend etwas anderes (KNX, RS485, LoxBus, CAN, DMX, etc.) zur Kommunikation/Steuerung im Eigenheim nutzt ist meiner Meinung nach völlig sekundär. Fällt diese "Grundlage" aus, hat man ein Problem.

Diese Aussage wäre korrekt, wenn andere Systeme wie DMX, CAN, LOXbus.. auch am "großen, weiten Internet" hängen würden, ist aber bei keinen dieser System so direkt vorgesehen. Auch sind alle von dir aufgezählten Systeme mehrpunkt Verbindungen es können also auf eine (Bus) Verbindung direkt mehrer Endpunkte hängen, es braucht hier primär keinen Vermittler (z.B. Switch) der einzelnen Punkt zu Punkt Verbindungen miteinander kommuzieren lässt.

Im übrigen ist UDP in Verbindung mit KNX auch insgesamt eine nicht to prikelnde Lösung, nachdem nicht sichergestellt werden kann, daß jede Info seinen Empfänger findet, KNX aber ein State basiertes System ist, könnten da lustige Probleme auftreten.

Für mich kommen aussdem Lösungen die ein Dritter nicht völling unabhängig von mir supporten kann nicht in systemkritische Teile der Installation.
Ich gehe immer davon aus, daß wenn eine Bastellösung ausfälle man damit auch in Zukunft einfach weiter leben kann ohne es wieder in Betrieb nehmen zu müßen. Wie schon erwähnt, aus meine persönlichen Erfahrung weiß ich, daß dies früher oder später passieren wird und man dann gegebenfalls nur die Dinge wieder in Stand setzen lässt die ein Dritter wieder hinbekommt.
Das Leben verändert sich und daß auch oft unvorhergesehen und drastisch.

Naja, soll jeder machen wie er will, wir können uns ja in 20 Jahre mal Treffen und uns über die zurückliegenden Jahre unterhalten ;-)