OpenKNX-Logikmodul release

[abeggled]

abeggled damit wir das besser eingrenzen können: Kannst du Mal versuchen, die knxprod auf deiner Platte erzeugen zu lassen, nicht auf OneDrive?
Nur um das als möglichen Grund auszuschließen.
Gruß, Waldemar

Hallo Waldemar, das ist ein "normales" lokales Verzeichnis, welches einfach noch synchronisiert wird. Bin mit Mike daran es einzugrenzen.

[thewhobox]

mumpf bei den knxprods fehlt (warum auch immer) die RegisterInfo.
Warum er es allerdings als "Projektsignatur" betitelt und nicht als Knxprod signatur ist mir ein Rätsel.

[mumpf]

abeggled damit wir das besser eingrenzen können: Kannst du Mal versuchen, die knxprod auf deiner Platte erzeugen zu lassen, nicht auf OneDrive?
Nur um das als möglichen Grund auszuschließen.
Gruß, Waldemar

[thewhobox]

Das Problem ist leider bekannt, aber noch keine Lösung gefunden.
Schreib mir mal eine pn mit deiner Email, evtl gibt es einen Workaround.

[abeggled]

Hallo OpenKNXler

Ich habe wollte gerade mein Logikmodul in Betrieb nehmen.
ETS 6.2.2, Tollbox 1.0.3

Toolbox sagt alles bestens:
image.png
Wenn ich jedoch die soeben erstellte .knxprod importieren möchte:
image.png

Jemand eine Idee?
Das Projekt als solches lässt sich einwandfrei öffnen.
Danke für Eure Hilfe.

[mumpf]

So, es gibt noch ein Weihnachtsgeschenk...

Die Version 3.5.2 ist seit heuteauf github verfügbar und kann auf der üblichen Hardware verwendet werden. Sie ist auch in den neusten Versionen vom VPM und Sensormodul verfügbar und wird nach und nach den Weg in die anderen Geräte finden.

Diese Version ist vor allem ein Hotfix-Release für das Logikmodul, leider hat sich in die ETS-Applikation ein Fehler eingeschlichen, der dazu führen kann, dass Logiken fehlerhafte AUS-Signale senden. Ich kann nur empfehlen, die Logik 3.4 nicht zu verwenden, egal in welchem Modul sie steckt.

Es sind auch noch 2 Infrastruktur-Verbesserungen dazugekommen:

• Beim Update über den KNX-Bus konnten wir die Anzahl an Telegrammwiederholungen reduzieren und so den Upload robuster machen
• Unsere Skripts zum Bauen der knxprod und auch die OpenKNX-Toolbox kommen jetzt mit der ETS 6.3.0 klar, fall die jemand installiert hat. Für die Toolbox bedeutet das, dass ihr ein Update auf die Version 1.0.3 braucht.

Wie immer sind alle Logikerweiterungen und Änderungen in der Applikationsberschreibung zu finden. Ich kann euch ein Update nur ans Herz legen und würde die 3.4 nicht verwenden.

Viel Spaß mit dem neuen Release,
Waldemar

[thewhobox]

Hallo Hendrik,

deine erste Aussage bestärkt mich weiterhin, dass das Problem am Weinzierl Interface liegt.
All deine bisherigen erfolgreichen Versuche gingen über den KNXD.

Ich denke hier wäre es ganz gut, mal einen sauberen Zustand herzustellen und es per Progger zu flashen

Zur Angegebenen Zeit: Ich meine mich zu erinnern, dass er den Parameter --pkg im letzten Release speichert.
Somit verwendet er nun 40 Bytes anstatt 128 Bytes, was die deutlich höhere Zeit erklären würde.
In einem internen Release ist das gefixt und wird auch ausgegeben, damit man es kontrollieren kann. Das ist aber leider noch nicht reif für ein öffentliches Release.
Falls du das trotzdem mal ausprobieren möchtest, melde dich gerne per PN oder so.

Gruß Mike

[henfri]

Hallo,

ich habe das erste (problematische) Sensormodul mit --pkg 40 und "Auto" (er wählt dann Tunneling über den KNXD) aktualisiert.
Beim dritten verbleibenden Modul habe ich kein --pkg eingegeben und es auch bei Auto belassen (weiterhin KNXD). Das hat auch geklappt.

Jetzt hab ich mich gefragt, warum sich das erste Modul anders verhalten hat.
Einen Verdacht habe ich: Es ist gar kein Sensormodul von Masifi, sondern ein UP1 von Ing-Dom. (aber zu meiner Verteidigung: Vor zwei Wochen war da noch ein Sensormodul ;-) )
Ich hab also die falsche FW hochgeladen. Ist nicht schlimm denke ich, da werden nur die GPIO falsch sein.
Aber es ist eine mögliche Erklärung für das andere Verhalten.

Also habe ich versucht den Fehler zu korrigieren und die richtige FW hochzuspielen. Dabei fällt auf:
die anderen Versuche - und auch der erfolgreiche Versuch die falsche FW auf den UP1 zu spielen hat 20 min gedauert.
Als ich das erste mal versucht habe, den UP1 mit der richtigen FW zu bespielen, war die prognostizierte Zeit 5000s. Leider ist das bei 75% abgebrochen.
Und jetzt kann ich gar nicht mehr programmieren - obwohl das Modul per ETS reagiert, sich neu starten lässt:

Version Client: 0.2.1
Version Client.Lib: 0.1.0
Werte in Klammern sind default
Bei leerer Eingabe wird default übernommen
PA des Geräts (1.0.35):
(Auto|Search|Tunneling|Routing)
Verbindungstyp:
Verbindungstyp: Auto
01 Tunneling -> 192.168.177.3:3671 (1.0.210) [knxd]
02 Routing -> 224.0.23.12:3671 (1.0.210) [knxd]
03 Tunneling -> 192.168.177.9:3671 (1.0.77) [KNX IP Interface 732 secure]
Es wurden 3 Gateways gefunden

IP-Adresse: 192.168.177.3
IP-Port: 3671
PA: 1.0.35

Info: Verbindung zum Bus hergestellt
Error: Zeitüberschreitung beim Warten auf antwort
at Kaenx.Konnect.Classes.BusDevice.WaitForData(Int32 seq, CancellationToken token)
at Kaenx.Konnect.Classes.BusDevice.DeviceDescriptorRe ad()
at Kaenx.Konnect.Classes.BusDevice.Connect(Boolean onlyConnect)
at KnxFileTransferClient.Program.Main(String[] args)

pkg hatte ich schon auf 5.


Gibt es hier noch eine Möglichkeit, oder muss ich mit dem Progger ran?
Und sorry für das Durcheinander...

Gruß,
Hendrik

[thewhobox]

Hallo henfri
was ich aus deinem Pastebin sehe, dass du da zwei utnerschiedliche Interfaces verwendest.
Bei dem wo es nicht funktioniert ist es das Weinzierl, bei dem wo es funktioniert der knxd.

Ich habe schon mehrfach berichtet bekommen, dass es mit dem Weinzierl nicht funktioniert.
Du könntest mal probieren verschiedene --pkg größen auszuprobieren. Default ist 128.

Denke eher, dass hier ein generelles Problem mit Weinzierl besteht, von daher würde eine vorab Version vom filetransfer nicht viel bringen.

Gruß Mike


P.s.: Restzeitangabe in m:ss steht nun auf der Todo.

[henfri]

Noch was ganz anderes, eine Idee:
Die Zeitschaltuhren habe ich:
- gerne im Logikmodul - aufgrund der Zuverlässigkeit
- gerne in Homeassistant - dann muss ich die Anpassungen nicht immer machen und dazu auch noch die ETS öffnen

Wenn das LM für die ZSU eine API per KO (Transfer-String artig per Text KO?) hätte und dieses von einer HomeAssistant Frontent konfigurierbar wäre... Das wär der Hammer.

Aber ich sehe auch ein, dass das vielleicht recht speziell ist.

HA kann natürlich durch jede Logik-Engine ersetzt werden.

[henfri]

Hallo,

hm, also einmal ging es mit tunneling, einmal nicht. Beide male lief es ultimativ über die Weinzierl. Aber in dem funktionierenden Fall war noch der KNXD dazwischen.
Schon erstaunlich, oder? Allerdings wissen wir auch noch nicht, ob es an der anderen Verbindung, oder an dem anderen (aber baugleichen) Gerät, oder sogar an den Kabeln lag.

--connect search fänd ich auch passender.
Und die Verbleibende Dauer fänd ich in Minuten:Sekunden besser. Aber das ist die Krische auf der Sahne :-)

Gruß,
Hendrik

[mumpf]

eilt nicht und ich helfe gerne beim noch robuster machen.

Danke schon mal. Evtl. schickt Dir thewhobox schon mal seine nächste Beta, das soll er entscheiden. Allerdings zieht er gerade um und ist deswegen seltener Online.

Ich habe einen knxd als Router und eine KNX-Schnittstelle (Weinzierl).

Ich hatte den knxd noch nie probiert, interessant dass es geht - war aber recht langsam. Ich bin bei mir mit der MDT-Schnittstelle oder unserem OpenKNX-Router bei ca. 350-400 B/s und das bei einer --pkg 128 (von mögichen 254), damit der Bus auch noch was anderes machen kann. 600 B/s hab ich auch schon gesehen, viel mehr wirst Du nicht erreichen bei max. theoretisch möglichen 1200 B/s.

In Zeit ausgedrückt: Update-Zeiten von 10-12 Min. sind das, was wir erreichen können, ohne den Bus lahmzulegen.

Wir können hier nur sammeln, mit welchen Interfaces/Routern es geht. Es war übrigens sicher Tunneling, das siehst Du daran:

IP-Adresse: 192.168.177.3
IP-Port: 3671
PA: 1.0.34
​

Routing macht auch noch eher Probleme.

Es sieht also so aus, als ob es mit dem Weinzierl nicht klappt. Ich vermute, es ist nicht Secure in Betrieb, oder? Sonst wäre das eine weitere mögliche Ursache.

Ich würde übrigens nicht --connect auto nehmen, sondern --connect search (werde ich auch noch in den Skripten ändern). Da fragt er nach einer Schnittstelle, bei Auto nimmt er die zuletzt genutzte.

Gruß, Waldemar

[henfri]

Hallo,

wie gesagt: eilt nicht und ich helfe gerne beim noch robuster machen.
Ich habe einen knxd als Router und eine KNX-Schnittstelle (Weinzierl).

Erfolglos war es über die Schnittstelle. Funktioniert hat es über den KNXD. Aber ich weiß nicht, ob über Tunneling oder Routing (kann vielleicht aus dem pastebin oben erkennen?)

[willisurf]

Das ist ja erstmal prima!

Waldemar oder Mike thewhobox wird sich bestimmt noch melden, daher ist es gut, ggf. noch etwas ausprobieren zu können.
Geht das Update bei Dir über einen Router?

[henfri]

Hallo,


ja, die ZIP ist komplett entpackt.

Ich melde mich in 1350 Sekunden (ca )

So, update ist durch (Firmware und Applikation!)

Ich versuche jetzt mal ein anderes Sensormodul (1.0.34) zu aktualisieren. Es ist baugleich.
Außerdem habe ich für die Verbindung "Auto" gewählt.

Also die 1.0.33 (baugleich, gleiche Sensoren) hat nicht funktioniert.
Beide Updates in der gleichen Powershell (d.h. ohne das Skript). Hier die gesammte Ein und Ausgabe:
https://pastebin.com/mY33Jh32

Ich habe jetzt noch zweimal das Sensormodul und ein Sen-UP1-8xTH und keinen Zeitdruck.
Ich könnte also durchaus verschiedene Szenarien testen.
Z.B.
- 1.0.33 (das erste, problematische Modul) mit "Auto" und ohne Skript (bei dem hatte ich bisher ja nur mit dem Skript probiert
- 1.0.25 (ein noch nicht ausprobiertes, identisches Modul) mit dem Skript (das wäre auch Auto, wenn ich es richtig sehe)

Ich kann aber auch andere Kombinationen probieren.

Oder ich bin glücklich einen Weg gefunden zu haben der geht und wir belassen es dabei.

Gruß,
Hendrik