Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Warum kann man, wenn automatisch beziehen eingestellt ist (dhcp), eigentlich noch eine IP Adresse in der ETS manuell eingeben?
das musst du die Entwickler der ETS fragen Klaus Gütter
Da in dem Feld die per DHCP bezogene IP-Adresse angezeigt wird, gehe ich davon aus dass es ein Bug ist, dass in diesem Fall das Feld schreibbar ist.
IMHO sollte es ReadOnly sein wenn es der Info dient.
und anschließend programmiert hat, sind halt die Schnittstellen IP/Multicast auch nicht mehr vorhanden. Und dann bleibt nur noch das Interface was auch in der Linie hängt.
das deutet darauf hin dass sich das Gerät warum auch immer irgendwie aufhängt..
Hier wäre ein Mitschnitt der Konsole hilfreich.
Bei mir läuft die aktuellste Version von ETS. Ich glaube es ist die 6.3.1 (Bin gerade unterwegs)
Multicast: Ja, aber wenn man versucht hat, eine manuelle IP zuzuweisen und anschließend programmiert hat, sind halt die Schnittstellen IP/Multicast auch nicht mehr vorhanden. Und dann bleibt nur noch das Interface was auch in der Linie hängt.
Ich meine aber ich habe es auch von dhcp IO Status aus gesehen (also dhcp und damit Multicast als Schnittstelle in der ETS vorhanden) probiert, was aber auch nicht geklappt hat.
Teste ich aber heute Abend noch einmal…
Warum kann man, wenn automatisch beziehen eingestellt ist (dhcp), eigentlich noch eine IP Adresse in der ETS manuell eingeben?
Ich hab das gestern mit RP und ESP HW getestet (allerdings mit der kurz vor Release stehenden 0.6.0 / 6.0.0-Dev, hier gabs aber keine Änderungen) beide Transistionen von DHCP auf statisch und von statisch auf DHCP.
Hat immer geklappt, aber:
Manchmal, wenn man "partiell programmieren" ausgewählt hat, hat die ETS keinen Neustart veranlasst nachdem es die Parameter am Gerät geändert hat.
Dadurch werden die geänderten Einstellungen dann nicht übernommen..
Schnittstelle -> MDT IP-Interface ( Gibt ja auch nichts anderes im Moment )
wie meinst du das?
Multicast sollte immer möglich sein.. Der Umweg über das Tunnelinterface und TP ist bei der Programmierung eines Routers doch Gaga..
Adresse eingeben (192.168.178.140 Ist nicht im DHCP Bereich.)
Netzmaske eingeben (255.255.255.0)
Gateway eingeben (192.168.178.1)
Schnittstelle -> MDT IP-Interface ( Gibt ja auch nichts anderes im Moment )
Programmieren / Physikalische Adresse und Applicationprogramm
Es wird Programmiert -> Gerät startet neu kann bis zu x Sek. dauern -> Gerät bekommt Application -> Abgeschlossen
Die IP wird immer noch in der ETS als Man. 192.168.178.140 angezeigt aber im Router (Unifi) ist noch die dhcp Adresse (192.168.178.211) vergeben.
Schnittstellen werden nicht in der ETS angezeigt.
Stelle ich nun auf Automatisch beziehen in der ETS Eigenschaften IP und geben dort die 192.168.178.211 ein (Die Adresse die ja automatisch bezogen wurde und auch im dhcp Bereich liegt) erscheinen die Schnittstellen in der ETS -> IP-Router läuft problemlos.
Eine Feste IP ist aber nicht möglich.
Moin, kurze Rückmeldung zu der 0.4.
Ich habe jetzt mal die 0.4 aufgespielt und kann keine feste IP vergeben.
Jedes Mal wenn ich in der ETS versuche eine feste IP zu vergeben, und anschließend den Router programmiere, kann ich anschließend den Router im Netzwerk nicht mehr ansprechen. Der Router behält die IP Adresse die er beim Erststart gezogen hat und ändert Sie nicht mehr.
Ändere ich auf IP automatisch beziehen und trage dann dort die zugewiesene IP ein, funktioniert der Router und ich kann die Schnittstellen in der ETS sehen.
Wozu kann ich hier überhaupt eine IP eintragen wenn sie doch automatisch bezogen wird?
Gibt es hier noch ein bekanntes Problem?
KNX Cache habe ich nach dem FW update gelöscht.
Es gibt eine neue Version der Applikation / FW: v0.4.0
Ist zum Teil ein Maintenance-Update mit neuestem Stack etc, aber vor allem wurde das Problem mit den Unicast / physikalisch adressierten Telegrammen zwischen Tunnel und KNX-TP entschärft.
Der Router leitet nun - so wie in der KNX Welt üblich - alle auf einem Tunnel eingehenden Unicast-Telegramme auf die TP Linie weiter. Auch wenn die PA nicht passt und auch wenn das Telegram dann über IP geroutet wird weil es eigentlich für eine andere Linie ist.
Da sollte das Problem mit der 15.15.255 beheben und auch bei so manch "unsauberen" Topologien helfen.
Was aber immer noch in Kraft ist: Wenn ein Unicast-Telegramm an eine Tunnel-PA adressiert ist (also an eine PA die in er ETS einem Tunnel des Router zugewiesen wurde) dann wird es NICHT auf TP geschickt.
Noch ganz allgemein:
Es gibt ab jetzt nur die die "Release" Applikation.
Die vorher als Beta bezeichnete Applikation heißt nun Dev und wird nur noch intern genutzt und keine Binaries mehr auf Github gestellt.
Alle die die alte "Beta" verwendet haben müssen also einmal neu aufsetzen, Update geht nicht.
Die neue Release-Applikation führt in der Ets beim Applikationsprogramm noch den Zusatz "-Beta" als Kennzeichnung für die "Reife". Wird dann mit einer v1.0.0 verschwinden
Today I updated the firmware. After configuring all ETS devices as routers, when other KNX devices were downloading, the gateway would restart at 80%, causing the download to fail. image.png image.png image.png
Everything was normal in version V0.3, and this problem did not occur. Please check where the problem is.
Es gibt eine neue Version der Applikation / FW: v0.4.0
Ist zum Teil ein Maintenance-Update mit neuestem Stack etc, aber vor allem wurde das Problem mit den Unicast / physikalisch adressierten Telegrammen zwischen Tunnel und KNX-TP entschärft.
Der Router leitet nun - so wie in der KNX Welt üblich - alle auf einem Tunnel eingehenden Unicast-Telegramme auf die TP Linie weiter. Auch wenn die PA nicht passt und auch wenn das Telegram dann über IP geroutet wird weil es eigentlich für eine andere Linie ist.
Da sollte das Problem mit der 15.15.255 beheben und auch bei so manch "unsauberen" Topologien helfen.
Was aber immer noch in Kraft ist: Wenn ein Unicast-Telegramm an eine Tunnel-PA adressiert ist (also an eine PA die in er ETS einem Tunnel des Router zugewiesen wurde) dann wird es NICHT auf TP geschickt.
Noch ganz allgemein:
Es gibt ab jetzt nur die die "Release" Applikation.
Die vorher als Beta bezeichnete Applikation heißt nun Dev und wird nur noch intern genutzt und keine Binaries mehr auf Github gestellt.
Alle die die alte "Beta" verwendet haben müssen also einmal neu aufsetzen, Update geht nicht.
Die neue Release-Applikation führt in der Ets beim Applikationsprogramm noch den Zusatz "-Beta" als Kennzeichnung für die "Reife". Wird dann mit einer v1.0.0 verschwinden
Mir ist aber aufgefallen das der Router nur am USB sofort Fehler auf der Konsole bringt das der EthernetChip nicht geht, auch die LEDs an der Buchse blieben aus. Erst nachdem ich zusätzlich (auch wenn man dies normal nicht machen sollte) KNX angeschlossen habe hat es funktioniert.
Das ist normal. Die Ethernetplatine wird aus der 21V Rail der BCU versorgt, und die hat dann bei USB natürlich 0V...
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Einen Kommentar schreiben: