EDOMI-Releases/Updates | Aktuell: Version 2.03

[baumhaus123]

Kurzes Feedback: 1.09 installiert, mit Enertex IP-Router funktioniert alles nach wie vor.

[gaert]

Sehr schön - danke!

[gaert]

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

[benji]

Hi,

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

was mache ich falsch???


Gruß Benjamin

[gaert]

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.

[Stoxn]

was mache ich falsch???
Gruß Benjamin

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...

[starwarsfan]

Hallo Christian

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

Siehe oben, lässt sich problemlos öffnen!?

[gaert]

Ah, sorry - mein Mac hatte die ZIP-Datei im Browser angezeigt... Daher wirre Zeichen

[KNXFan1970]

1.09 installiert - Kommunikation über Weinzierl KNX IP Interface 730 funktioniert weiterhin ohne Probleme.

gaert - Vielen Dank für deine Arbeit - wirklich eine tolle Software, die du da über Jahre geschaffen hast.

[gaert]

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...).

[gaert]

KNXFan1970
Danke für's Feedback - und überhaupt

[starwarsfan]

Hallo Christian

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.

[gaert]

Viel Glück

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...

[gaert]

Version 1.10 ist fertig...

Changelog:

• 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.

Viel Erfolg!

[starwarsfan]

Moinmoin miteinander

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.