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.
Das ist klar, da ich von meinen über 1000 GAs nur eine Handvoll konfiguriert habe. Was ich an dieser Stelle schmerzlich vermisse, ist...
Recht hast Du - die Sache mit .knxproj ist in der Pipeline, aber noch nicht angegangen. Also keine Sorge - der Tag wird kommen. Bis dahin kannst Du Dir ja zumindest per OPC-Export behelfen - besser als nix
Ich habe mir die .knxproj schon häufiger angeschaut - allerdings werde ich nicht so wirklich schlau draus. Zwar finde ich meine GAs wieder etc., aber der DPT ist irgendwie auch nur manchmal angegeben... Eine Doku wäre nicht schlecht
Evtl. werde ich beim nächsten Update optional quasi das alte Vorgehen anbieten (also nur CE, ohne DE). Ist halt irgendwie "unsauber", daher wäre es schon sinnvoller, wenn Dein Routerupdate erfolgreich wäre...
Besonders "dämlich" von Deinem Interface ist's natürlich, dass es den DE bestätigt, aber dann lieber doch auf dem CE sendet...
Das Verhalten war wohl offensichtlich ein Bug. Habe eine passende VM gefunden und das IP-Interface auf die Version 1.030 aktualisiert. Und was soll ich sagen, es funktioniert bestens!
Das Tracelog ist nun dahingehend sauber, die Visu funktioniert wieder. "Dahingehend" deshalb, weil es natürlich nach wie vor sehr viele Error-Einträge gibt, welche aber ausschliesslich Meldungen des Typs
ROUTER @ DE | TUNNELING_REQUEST:L_Data.ind / Typ: Write / ErrMsg: Unbekannte GA ...
sind. Das ist klar, da ich von meinen über 1000 GAs nur eine Handvoll konfiguriert habe. Was ich an dieser Stelle schmerzlich vermisse, ist... Achnein, das gehört nicht hierher. Ich mach' ein separates Posting auf.
Super Sache, freut mich, dass ich weitermachen kann.
Email senden: Reply-Codes des Mail-Servers werden im Fehlerfall geloggt
OpenSSL (CentOS-Paket) wird geupdated, da einige Nutzer Probleme mit dem Email-Versand hatten und das Problem offenbar an einer veralteten OpenSSL-Version seine Ursache hatte.
HTTP/UDP-Requests: Es können nun Variablen (KO-Werte) eingesetzt werden (ACHTUNG: Nicht getestet!)
HTTP-GET: In der URL kann {KO-ID} bzw. {GA} an beliebiger Stelle eingefügt werden (siehe aktualisierte Doku)
UDP: In den UDP-Daten (nicht in IP:Port) ebenfalls
(Shell-Befehle betrifft dies aktuell nicht)
Logikbausteine:
Die Ordner der Logikbausteine sind umbenannt worden (dies hat keine Auswirkungen auf die Funktionalität).
Der Ordner 19 ("Sonstige") heisst nun "Community-Bausteine" und soll dem Austausch von LBS dienen
in diesem Zusammenhang wurde der LBS 19000300 (Schwellenwert) als Deprecated umbenannt, da dieser eigentlich nicht in Ordner 19 gehört
Der Schwellenwert-Baustein befindet sich nun im Ordner 15 (15000020) - vorhandene Logiken sollten ggf. auf diesen Baustein umgestellt werden, da der Baustein 19000300 in Zukunft entfernt wird
diverses Kleinzeugs...
Wichtig:
Beim Update werden diverse Konsolenausgaben erfolgen (aka wirre Zeichen) - dies ist normal und zu ignorieren
Auch Wichtig:
Generell werden bei einem Update immer die Original-Logikbausteine (die bei der EDOMI-Installation dabei sind) überschrieben, d.h. falls Ihr einen dieser LBS irgendwie verändert haben solltet, gehen diese Änderungen verloren. Dies betrifft nicht(!) die LBS, die unter einen neuen ID von Euch erstellt worden sind.
Evtl. werde ich beim nächsten Update optional quasi das alte Vorgehen anbieten (also nur CE, ohne DE). Ist halt irgendwie "unsauber", daher wäre es schon sinnvoller, wenn Dein Routerupdate erfolgreich wäre...
Besonders "dämlich" von Deinem Interface ist's natürlich, dass es den DE bestätigt, aber dann lieber doch auf dem CE sendet...
Aber der Router sendet nun "Telegramme", d.h. auf Deinem Bus ist halt irgendwas los. Das ist ja auch gut so... Allerdings sendet der Router dummerweise auf dem CONTROL-Endpoint:
ROUTER @ CE | UNKNOWN / Unbekannter CRD: 420h
Der CRD 0420h ist ein Tunneling_Request, d.h. der Router hat ein Telegramm empfangen (vermutlich vom Bus) und möchte EDOMI nun daran teilhaben lassen. Dies gehört aber auf den DATA-Endpoint - und diesen hat der Router beim Verbinden (s.o.) selbst bestätigt!!
Daher tippe ich auf ein Problem mit der Firmware o.d.G. - das Ding kennt vielleicht die neue Spec noch nicht. Daher funktionierte es auch mit der Version 1.08, den da gab es diese Unterscheidung zwischen DE und CE noch nicht (zum Nachteil wiederum von neueren Routern...).
Vielen Dank für die Erläuterungen, das leuchtet mir ein. OK, dann muss ich mal suchen, ob ich noch irgendwo eine alte Win-VM herumschwirren habe, um diese für das Update zu missbrauchen. Ich gebe natürlich Bescheid, wie's ausgegangen ist.
Ok - sieht eigentlich (zunächst und formal) korrekt aus. Aber....
Ich erklär's mal ein wenig:
Als erstes fordert EDOMI vom Router (ich weiß, Schnittstelle) eine "Selbstauskunft" an:
EDOMI @ CE | DESCRIPTION_REQUEST an 192.168.23.106:3671
Der Router antwortet (u.a.) mit:
ROUTER @ CE | DESCRIPTION_RESPONSE / Status: Ok / Name: Enertex KNXnet/IP Interface / PA: 15.15.1 / MAC: 0050c2793361
Alles gut. Jetzt fordert EDOMI eine Tunnelverbindung an:
EDOMI @ CE | CONNECT_REQUEST an 192.168.23.106:3671
Router freut sich und antwortet korrekt:
ROUTER @ CE | CONNECT_RESPONSE / CE: 192.168.23.214:50000 - 192.168.23.106:3671 / DE: 192.168.23.214:50001 - 192.168.23.106:3671 / Tunnel-PA: 15.15.11 / ChannelID: 65
Bis hierhin ist alles perfekt! Vor allem aber bestätigt der Router den Data-Endpoint:
DE: 192.168.23.214:50001 - 192.168.23.106:3671
Den Control-Endpoint (CE) haben EDOMI und der Router ja bereits die ganze Zeit zur Unterhaltung genutzt.
In der Folge passiert (bis auf Heartbeat) garnichts, d.h. EDOMI sendet keine Telegramme oder Read-Requests. Ich denke mal, dass Du nichts dergleichen konfiguriert hast.
Aber der Router sendet nun "Telegramme", d.h. auf Deinem Bus ist halt irgendwas los. Das ist ja auch gut so... Allerdings sendet der Router dummerweise auf dem CONTROL-Endpoint:
ROUTER @ CE | UNKNOWN / Unbekannter CRD: 420h
Der CRD 0420h ist ein Tunneling_Request, d.h. der Router hat ein Telegramm empfangen (vermutlich vom Bus) und möchte EDOMI nun daran teilhaben lassen. Dies gehört aber auf den DATA-Endpoint - und diesen hat der Router beim Verbinden (s.o.) selbst bestätigt!!
Daher tippe ich auf ein Problem mit der Firmware o.d.G. - das Ding kennt vielleicht die neue Spec noch nicht. Daher funktionierte es auch mit der Version 1.08, den da gab es diese Unterscheidung zwischen DE und CE noch nicht (zum Nachteil wiederum von neueren Routern...).
starwarsfan
Der Tracelog besteht nur aus wirren Zeichen...? Da ist wohl etwas schiefgelaufen beim Speichern im Browser
Vermutlich eher bei Dir beim Speichern. Hab's eben aus meinem Posting heruntergeladen, entpackt und kann das Log problemlos anzeigen. Genauso, wie es ursprünglich aussah...
Ungeachtet dessen bin ich mir ziemlich sicher, dass Dein Interface nur auf dem Control-Endpoint "funkt". Dieses Verhalten zu implementieren wäre keine große Sache für mich: Man könnte in der Konfiguration entscheiden, ob das Interface/Router beide "Kanäle" nutzt oder nur einen. Bevor ich mich aber ans Werk mache, wäre ein lesbarer Tracelog durchaus nützlich... Wenn die Kinder schlafen kannst Du ja nochmals versuchen den Log zu speichern
Klick mal auf Visualisierung und wähle dann die entsprechende Visu aus. Glaube hatten wir hier schon mal; ist nicht ganz intuitiv, aber auf den Geräten hinterlegst Du einen Link, der Visu, Account und Passwort enthält...
Vermutlich das übliche: Im Login-Dialog zunächst auf "Visualisierung" klicken - und dann die gewünschte Visu auswählen (bei Dir gibt's vermutlich nur eine). Oder die Visu-ID und ggf. Logindaten gleich in der URL mit angeben - siehe Doku.
also ich hab mich dann heute auch mal Endomi gewidmet. Hab nun VM auf meinem MBP installiert und wollte mal ein wenig testen, habe mir eine kleine Visumseite im Projekt erstellt. Visuaccount habe ich auch angelegt, jetzt wollte ich mir die Visumseite mal anschauen kann mich allerdings nicht einloggen unter Endomi-Server/visu
starwarsfan
Der Tracelog besteht nur aus wirren Zeichen...? Da ist wohl etwas schiefgelaufen beim Speichern im Browser
Ungeachtet dessen bin ich mir ziemlich sicher, dass Dein Interface nur auf dem Control-Endpoint "funkt". Dieses Verhalten zu implementieren wäre keine große Sache für mich: Man könnte in der Konfiguration entscheiden, ob das Interface/Router beide "Kanäle" nutzt oder nur einen. Bevor ich mich aber ans Werk mache, wäre ein lesbarer Tracelog durchaus nützlich... Wenn die Kinder schlafen kannst Du ja nochmals versuchen den Log zu speichern
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: