OpenKNX IP-Router

[kuala]

Hallo Ing Dom

die PA hatte ich am Anfang schon auf 1.1.0 gestzt.
Leider hat es da auch schon nicht funktioniert.

[Ing-Dom]

äh - du hast dem Router die 1.1.13 gegeben? Stimmt das?
Router müssen grundsätzlich eine .0 PA bekommen, also in dem Fall 1.1.0.
Ob das die Ursache ist, weiß ich aber nicht..

[kuala]

sorry, xml nimmt er nicht.

Jetzt habe ich die XML gezipt.

[Ing-Dom]

als Screenshot der csv datei, ernsthaft?
ETS xml bräuchte ich..

[kuala]

anbei meine Aufzeichnung:

vielen Dank

grafik.png

[Ing-Dom]

Die KNX und die LAN LED leuchten dauerhaft. Bei der Version 2.12.3 blinken diese beiden LEDS immer mal wieder auf.

das passt. Leuchten bedeutet "Verbindung vorhanden" und kurzes ausgehen "Aktivität".

Bitte öffne beim Programmieren des Router in der ETS den Gruppenmonitor und zeichne den Programmierversuch auf - und stelle ihn hier ein.

[kuala]

Hi,

ich programmiere über die Eibmarkt KNX/IP interface 730.

Das Gerät reagiert auf die Prog taste. bei Drücken läuchtet diese dauernt und auch die ETS fängt das programmieren an.

Die KNX und die LAN LED leuchten dauerhaft. Bei der Version 2.12.3 blinken diese beiden LEDS immer mal wieder auf.

[Ing-Dom]

Aber wenn ich jetzt die physikalische Adresse programmieren will, dauert es sehr lange und bricht irgendwan ab.

über welche Schnittstelle versuchst du es?
Routing, Tunnel oder über TP (andere Schnittstelle) ?

Reagiert das Gerät auf das drücken der Progaste? Wie sehen und lan und knx leds aus?

[kuala]

Hallo Ing-Dom,

so hatte jetzt auch mal die Zeit, die Version Beta 5 zu testen. Leider ist dies nicht mit Erfolg gekrönt.

Ich habe die Firmware aus dem Link im Forum geladen.
Danach das Zipfile in die OpenKNXToolbox importiert. In dem Tool selber bekomme ich die Firmware nicht angezeigt, aber im Verzeichnis openKNX Toolbox \ storage.

Hier habe ich das File "USB-Upload-Firmware-IP-Router-REG1-Eth.ps1" mit Powershell geöffnet und an den IP Router übertragen.
Soweit so gut.
Danach die KNXprod erzeugt und in die ETS 5.7.7 importiert. Funktioniert auch noch.

Aber wenn ich jetzt die physikalische Adresse programmieren will, dauert es sehr lange und bricht irgendwan ab.
Dies habe ich bei der Version 2.12.3 nicht.

VG Jens

[Ing-Dom]

ok - noch nicht so viel Feedback aus dem Feld wie ich mir das gewünscht hatte ^^

Dachte die Möglichkeit für 16 Tunnel und Reservierung trifft den Bedarf. Dass es ruhig ist, kann aber auch Bedeuten dass es einfach funktioniert..

Falls das so ist, bitte kurzes Feedback zu Beta 5.0, ob alles so läuft wie erwartet oder ob Probleme auftreten.

[Ing-Dom]

Dann habe ich versucht das Namensschema zu verstehen:

Ja, das war das Problem ^^
Es gibt zwar ein Schema, aber das hab ich mit der Einführung der neuen Plattform geändert. REG1-Eth war irgendwie nicht so intuitiv, auch REG1-Base-IP nicht.

Ein Anwender braucht das Schema aber eigtl nicht dekodieren, denn es gibt hier eine Übersicht aller verfügbaren Geräte:
https://github.com/OpenKNX/OpenKNX/wiki/Device-Overview
Wir geben uns auch mehr Mühe, die Geräte eindeutig und einheitlich zu benennen.

- Base - soll bestimmt die Basisplatine mit gemeint sein, in die die BCU eingelötet wird.

Base bedeutet "Basismodul", also dass da noch Platz für eine Erweiterungsplatine ist.

REG1-Base: Grundgerät ohne Applikations-PCB mit TP (da TP unser Standard ist, wird es weggelassen)
REG1-LAN-TP-Base: Grundgerät ohne Applikations-PCB mit LAN + TP
REG1-LAN-Base: Grundgerät ohne Applikations-PCB mit LAN
...
REG1-LAN-GW-RF2G4: Gerät mit LAN und 2.4GHz Funkplatine...

Wenn ein Router keine KOs haben kann, dann als zusätzliche parallel laufende Applikation?

ja, das wäre der Weg, der zu gehen wäre. Aber das kann unser stack und Framework aktuell nicht, das wäre auch viel Aufwand das zu bauen - mit begrenztem Nutzen.

Wäre schon cool das zu haben und der Router (als Hardware) wäre als Verbindung zwischen IP/TP auch der ideale Ort dafür, die synchrone Zeit auf den KNX-Bus zu bringen.

Ja, irgendwie schon, aber irgendwie auch nicht.
Der Router soll routen, und zuverlässig und stabil laufen (und nicht zB Telegramme verlieren weil gerade der Poll vom NTP per IP ein paar ms zu lange dauert.

Kommt denn der sendende NTP-Client für die neue ESP-Basis?

Insofern, ja, aber nicht in der Router-Applikation.
Ganz konkret haben wir schon diverse "Gateway"-Projekte am Start, wo man sowieso mind. ein zweites KNX-IP Gerät braucht bzw. haben will, dass dann diese Sachen übernimmt, inkl. Zeitserver.

Mich würde auch interessieren, ob der Verbrauch jetzt speziell aus der rp2040 Plattform resultiert oder allgemein bei einer 100MBit Verbindung auftritt.

Es ist die Physik die hier den höheren Stromverbrauch erzeugt, da lässt sich auch nicht viel machen. Beim RP2040 ist das die SPI Ethernet Mac-Phy (w5500) die 80mA statt 120ma braucht.

[traxanos]

Kommt denn der sendende NTP-Client für die neue ESP-Basis?

Nein ein Router kann keine KOs senden. Der NTP hat nur Vorteile für die Gerätekonsole. Du wirst später einfach einen Zweiten brauchen, der die neuen InternetServices beinhaltet. Da ist dann nicht nur NTP also Zeitgeber enthalten sondern auch sowas wie Wetter

Dann habe ich versucht das Namensschema zu verstehen

So einfach ist das nicht, da es kein echtes Schema gibt. Das ist alles historisch gewachsen und wenn man nicht jetzt rückwirkend alle Geräte umbenennen möchte um es in ein verständliches Namensschema zu quetschen, wird sich daran leider auch nichts ändern.

Also es ist einfach nur irgend eine eindeutige ID und du musst dir merken Welche ID deine HW hat.

[olemaan]

Guten Morgen,

die Verwirrung kam allein schon aus der Tatsache zustande, dass es mehrer Scripte gab. Dann habe ich versucht das Namensschema zu verstehen:
Ich habe ja ein (ich zitiere aus dem Wiki: "KNX-TP Reiheneinbaugerät für 35mm Hutschiene und REG1-App-Eth Erweiterung mit 10/100Base-T Ethernet"
Also versuche ich zu lösen:
- REG1- klar, ich habe ja ein Reiheneinbaugerät
- ETH- Ethernet habe ich am Gerät
- LAN - Häh? Wäre an diesem Gerät ja auch Ethernet
- TP- Habe ich auch am Gerät. Es gibt ja noch ein Gerät mit IP und ohne TP
- Base - soll bestimmt die Basisplatine mit gemeint sein, in die die BCU eingelötet wird.

Aber ETH/LAN konnte ich nicht logisch auflösen. Dann kratzt man sich am Kopf und guckt ins Wiki und da stehen dann ganz andere Bezeichnungen. Aber alles gut, das sind jetzt wirklich belanglose Luxusprobleme eines zufriedenen Anwenders. 😊

Ich hab auch keine REG1-ETH mehr und werde auch keine mehr bauen (Nachfolger wird der REG1-LAN-TP-Base).

Das habe ich mir dann auch gedacht, da ich den zitierten Thread verfolgt habe.

dazu kommt das der ntp auch für die rp2040 plattform garnicht verfügbar ist

NTP würde ich gerne drin lassen, beim ESP klappt der und sorgt für eine korrekte Zeit auf dem System

Kommt denn der sendende NTP-Client für die neue ESP-Basis? Wenn ein Router keine KOs haben kann, dann als zusätzliche parallel laufende Applikation? Wäre schon cool das zu haben und der Router (als Hardware) wäre als Verbindung zwischen IP/TP auch der ideale Ort dafür, die synchrone Zeit auf den KNX-Bus zu bringen.

Die 10MBit hätte ich auch gern zurück.

Mir hat erst diese Option bewusst gemacht, dass die 100Mbit so ca. 0,3 W mehr verheizen. Da man die Geschwindigkeiten in diesem Anwendungsfall fast nie braucht, fand ich die Einsparung cool, auch wenn sie praktisch sicherlich nicht den Kohl fett macht. Mich würde auch interessieren, ob der Verbrauch jetzt speziell aus der rp2040 Plattform resultiert oder allgemein bei einer 100MBit Verbindung auftritt.

Viele Grüße
Ole

[Ing-Dom]

Da bleibt nicht viel hinzuzufügen, Marco und Waldermar haben eigentlich alles gesagt was es da zu sagen gibt.

Doch... derzeit gibt es eben nur das REG1-Eth. Und der steht auch im Wiki: https://github.com/OpenKNX/OpenKNX/wiki/REG1-Eth

Den REG1-LAN-TP-Base gibt es noch nicht public, das wird sicherlich noch von Ing-Dom separat angekündigt und wird dann auch im Wiki stehen.

Richtig, REG1-ETH ist korrekt. Evtl war die Verwirrung weil es mal REG1-Eth-V0 und V1 gab, aber vom V0 gabs nur 3 Prototypen die mittlerweile obsolet sind.. daher ist das V0 Target weggefallen.

Ich hab auch keine REG1-ETH mehr und werde auch keine mehr bauen (Nachfolger wird der REG1-LAN-TP-Base).

Das REG1-LAN-TP-Base ist eine HW auf ESP-Basis.. siehe auch
https://knx-user-forum.de/forum/proj...95#post2010195


NTP würde ich gerne drin lassen, beim ESP klappt der und sorgt für eine korrekte Zeit auf dem System.. was für spätere Erweiterungen interessant sein könnte.
Aber richtig, Senden kann er nicht und wird er nie können.
Sind halt generische Texte.

Die 10MBit hätte ich auch gern zurück. Für den ESP versuche ich das aktuell hinzubekommen, um erstmal überhaupt zu sehen wieviel es bringt...
Aber ist tief im ip stack "versteckt" und schlecht zugänglich.

[traxanos]

Die Option für den stromsparenden 10Mbit-Modus ist weggefallen? Hat ja doch so knapp 10mA gespart.

der integrierte lwip stack hat leider keine option um die 10mbit zu setzen.

Nur für die Liste, ich denke es ist nur für mich gerade relevant, es wird ohne DHCP-Server weiterhin keine lokale Adresse aus dem Bereich 169.254.0.0/16 vergeben.

auch das sieht das framework nicht vor.

Hab den NTP-Client mal aktiviert.In der Hilfe steht: "Stattdessen stehen drei neue Kommunikationsobjekte zur Verfügung, mit denen Zeit, Datum und beides kombiniert auf dem Bus bereitgestellt werden können."

das ist netzwerk modul ist generisch. und damit auch die hilfetexte. der router ist eine ausnahme. dazu kommt das der ntp auch für die rp2040 plattform garnicht verfügbar ist. das ist leider der nachteil von generischen bausteinen.