Modul 10_KNX.pm - support

[erwin]

Hmmm,
geschrieben hab ich:

re KNX_scan: hab ich noch nie in Kombination mit TUL- oder KNXTUL-Modul getestet....
update: KNX_scan geht mit TUL und KNXTUL definitiv nicht, weil es bei diesen Modulen kein reading state:connected gibt. Muss mir überlegen, ob ich das implementierfen will...., alternativ cmd-ref Hinweis dazu schreibe.

und einen fix für TUl / KNXTul werde ich sicher nicht machen, weil:
1) ich nicht der Maintainer dieser Module bin. Daher "darf" ich das gar nicht!
2) meine Zeit lieber in jene Module investiere, wo ich es sinnvoll finde.
3) ich hab nie von einem fix gesprochen, ich hab lediglich begründet, warum es mit diesen Modulen nicht funktioniert.
4) es eine Alternative für diese Module gibt, die seit 2018 nicht mehr gewartet wurden.
PS: ich hab mich für den cmd-ref Hinweis entschieden, ich hoffe das ist eindeutig!
Mit lokalen Änderungen an Modulen wird der support sehr mühsam!

Hat wunderprächtig funktioniert, bis Dein richtiger "fix" kam...

...auch wenn du es wiederholst: es hat nicht funktioniert, siehe: https://forum.fhem.de/index.php?topic=133667.0

[jw9]

Fassen wir zusammen:

Es hat vor dem Fix nicht funktioniert.

Es funktioniert nach dem Fix nicht.

Was hat de Fix gebracht?

[jw9]

Mit lokalen Änderungen an Modulen wird der support sehr mühsam!

Die lokalen Änderungen haben den Hintergrund dass ich dabei bin, das Modul komplett zu überarbeiten. Das läuft mittlerweile mit dem TPUART-Interface sauber und stabil und auch schlank ganz ohne Umwege über den knxd-Moloch.

Ich frage mich aber mittlerweile, ob das eine gute Idee war...

[erwin]

Dann fasse ich auch zusammen:
Es funktioniert mit diesem fix wie in der cmd-ref beschrieben.
seltsam ist dein letzter post:

Es hat vor dem Fix nicht funktioniert.

... am 27.6. hast du geschrieben:

Doch! Es hatte funktioniert! bis zu dem "fix"...

Ich kenn mich nicht mehr aus. 

[jw9]

Es funktioniert mit diesem fix wie in der cmd-ref beschrieben.

Mit KNXTUL?

seltsam ist dein letzter post:

Es hat vor dem Fix nicht funktioniert.

... am 27.6. hast du geschrieben:

Doch! Es hatte funktioniert! bis zu dem "fix"...

Ich kenn mich nicht mehr aus. 

Was bitte ist daran seltsam? Ich hatte doch alles erläutert.

Es hatte funktioniert, mit der einen zusätzlichen Zeile in KNXTUL, wie in #119 geschrieben. Diese Zeile liefert das erforderliche Connect-event.

Bei Dir hingegen, hat es mit KNXTUL weder vor dem Fix funktioniert, noch nach dem Fix.

Und jetzt funktioniert es mit KNXTUL eben nicht mehr, auch nicht mit dieser Connect-Zeile.

Es bleibt die Frage, was der Fix (also das Verschieben der Funktionalität in KNXIO) gebracht hat und welchen Zweck er erfüllen soll?

Der Scan ist eine generelle Funktionalität, die nicht abhängig von irgend einem bestimmten IO-Device ist. Das einzige, was vom IO-Device kommen muss ist das connect-/disconnect event. Der Rest des Scan-Vorgangs hat rein gar nichts mit dem IO-Device zu tun und gehört somit auch nicht dort hin.

Insbesondere sind die Kommunikationsobjekte (also das, worum sich der scan kümmern soll) nicht im IO-Device angesiedelt, sondern im KNX-Modul. Da gehört die Scan-Funktionalität auch hin.

Just my $0.02...

[erwin]

Mit KNXTUL?

NEIN...auch nicht mit TUL: siehe cmd-ref

es hatte funktioniert, mit der einen zusätzlichen Zeile in KNXTUL, wie in #119 geschrieben. Diese Zeile liefert das erforderliche Connect-event.

Wenn man mit gepatchen Modulen argumentiert, kann man jeden support ad absurdum führen.

Es bleibt die Frage, was der Fix (also das Verschieben der Funktionalität in KNXIO)...

KNX_scan ist ein neues Utility, und um die Diskussion zu vermeiden, warum das mit TUL/KNXTUL nicht geht... und ich keinen support für diese Module leisten kann/will!
Ich gebe dir aus Architektur-Sicht recht, hätte die Funktion im KNX Modul belassen können und die IO-dev TUL/KNXTUL mittels error-msg ausschließen...
Aber ich wiederhole mich: cmd-ref lesen, falls irgendwas dort beschriebene nicht funktioniert, gebe ich gern support!

[jw9]

Mit KNXTUL?

NEIN...auch nicht mit TUL: siehe cmd-ref

Ähm, ich muss mich an dieser Stelle korrigieren: ich verwende/überarbeite nicht KNXTUL, sondern TUL.

Das aktuell in fhem enthaltene TUL ist tatsächlich komplett kaputt. Der Autor des Moduls hatte offensichtlich das Datenblatt des tpuart-Chips entweder nicht gelesen oder nicht verstanden.

Das ist auch der Grund, warum ich das von Grund auf neu schreibe.

Dass ich das in einem halb-fertigen Zustand nicht veröffentlichen will wirst Du hoffentlich nachvollziehen können.

Wenn man mit gepatchen Modulen argumentiert, kann man jeden support ad absurdum führen.

Es geht nicht um ein gepatchtes Modul, sondern um ein komplett überarbeitetes bzw neu geschriebenes. Das nur nebenbei.

Und ich argumentiere auch nicht damit. Es gibt schlicht keinen vernünftigen Grund diese Funktionalität in das IO-Modul zu verschieben. Sonst müsste jedes Modul diese Funktionalität duplizieren. Auch die Kommunikationsobjekte, um die sich der scan ja kümmert, sind nicht im IO-Modul beheimatet sondern im KNX-Modul.

Es geht auch nicht um Support: die Zeile mit dem connect konnte ich auch selbst hinzufügen.

Und ich kann Dir versichern, dass aktuell ausser mir niemand TUL verwendet. Ganz einfach aus dem Grund, dass das mit fhem aktuell ausgelieferte Modul schlicht nicht funktioniert -- zumindest nicht mit tpuart. Und wer NICHT tpuart verwendet, für den gibt es auch keinen Grund nicht auf KNXIO umzusteigen.

Insofern ist also auch keine Flut von Support-Anfragen zu erwarten.

Und nein: für mich ist es keine Option auf KNXIO umzusteigen, weil mein KNX-Router verschlüsselt kommuniziert und weder KNXIO noch knxd das können...

 

KNX_scan ist ein neues Utility, und um die Diskussion zu vermeiden, warum das mit TUL/KNXTUL nicht geht... und ich keinen support für diese Module leisten kann/will!

Nun, es gibt keinen Grund warum andere IO-Devices nicht mit dem scan funktionieren sollten -- sofern sie überhaupt funktionieren. Der scan macht nichts anderes als die stinknormale KNX-Kommunikation ebenfalls. Die einzige zusätzliche Voraussetzung ist der connect.

Ich gebe dir aus Architektur-Sicht recht, hätte die Funktion im KNX Modul belassen können und die IO-dev TUL/KNXTUL mittels error-msg ausschließen...

Nein, auch keine error-msg. Einfach so belassen wie es war. Lediglich in der Doku zum KNX-Modul die anderen Module als "deprecated" erklären.

[erwin]

Falls dein neu geschriebenes Modul irgendwann mal im SVN zu finden ist, bin ich gerne bereit,
die Funktion wieder ins KNX-Modul zu verschieben, auch wenn das etwas Aufwand bez. dem neuen Attr. enableKNXscan im KNXIO Modul bedeutet.
Solange es nur EIN IO-Modul gibt, das (in der SVN-version) das unterstützt, ist es relativ egal, wo die Funktion sitzt. Streng genommen ist es im KNX-Modul unnötiger/nicht funktionaler code, falls TUL/KNXTUL als IO-dev verwendet wird.
Und lt. Statistik von heute verwenden etwa 90 user das TUL-Modul, wieviele davon mit TP-UART ? keine Ahnung, jedenfalls wurde  schon 2018 davon abgeraten und via knxd empfohlen, weil hier das TP1 protokoll nicht vollständig implementiert ist...(Ack, error-recovery).

Es geht auch nicht um Support: die Zeile mit dem connect konnte ich auch selbst hinzufügen.

Das du die Zeile hinzufügen kannst, glaube ich dir! Es geht dann sehr wohl um den support: Jeder support geht davon aus, dass es sich um ein Problem mit dem aktuellen code aus dem SVN handelt!
Bin schon gespannt auf deine Implementation mit Verschlüsselung.

[jw9]

die Funktion wieder ins KNX-Modul zu verschieben, auch wenn das etwas Aufwand bez. dem neuen Attr. enableKNXscan im KNXIO Modul bedeutet.

Dieses Attr wäre doch wohl ebenfalls besser im KNX-Modul aufgehoben?

Solange es nur EIN IO-Modul gibt, das (in der SVN-version) das unterstützt, ist es relativ egal, wo die Funktion sitzt.

Mit dieser Argumentation kannst Du auch gleich KNX und KNXIO zu einem Modul zusammenwürfeln...

Streng genommen ist es im KNX-Modul unnötiger/nicht funktionaler code, falls TUL/KNXTUL als IO-dev verwendet wird.

Eben nicht!

Bin schon gespannt auf deine Implementation mit Verschlüsselung.

Eben NICHT mit Verschlüsselung, sondern ein funktionierendes tpuart, das DIREKT mit dem Bus verbunden ist. Nix knxd, nix Ethernet, nix Router, nix Verschlüsselung.

Aber ich lerne ja gerade, wie gross Teamarbeit hier geschrieben wird. Bin mir nicht mehr so ganz sicher ob ich in einem Team mitspielen will wo man sich bewusst gegenseitig Steine in den Weg legt...

Schönen Tag noch...

[erwin]

Eben NICHT mit Verschlüsselung, sondern ein funktionierendes tpuart, das ...

aber einen Tag vorher:

Und nein: für mich ist es keine Option auf KNXIO umzusteigen, weil mein KNX-Router verschlüsselt kommuniziert und weder KNXIO noch knxd das können...

... bin verwirrt und gebe auf!
Das Angebot einer Kooperation steht nach wie vor!

[jw9]

Eben NICHT mit Verschlüsselung, sondern ein funktionierendes tpuart, das ...

aber einen Tag vorher:

Und nein: für mich ist es keine Option auf KNXIO umzusteigen, weil mein KNX-Router verschlüsselt kommuniziert und weder KNXIO noch knxd das können...

... bin verwirrt und gebe auf!

Hättest Du mal die Beiträge die Du zitierst gelesen, dann wäre auch keine Verwirrung entstanden.

Hier also noch einmal:

Mein KNX-Router verschlüsselt. Und das bleibt auch so, weil ich keine unverschlüsselte Kommunikation im (W)LAN haben will. Schon gar nicht will ich unverschlüsselte Kommunikation im (W)LAN haben, über die man auf die Hausautomatisierung zugreifen kann.

Weder KNXIO noch knxd können Verschlüsselung. Somit ist ein Umstieg auf KNXIO keine Option.

Das tpuart-Modul (das den KNX-Bus direkt auf einem USB-Port zur Verfügung stellt) ist sehr wohl eine Option, weil hier die Kommunikation nicht über (W)LAN geht und somit nicht zwangsläufig verschlüsselt sein muss.

Das Angebot einer Kooperation steht nach wie vor!

Hmmm..

Also bislang stellt sich die "Kooperation" für mich so dar, dass aus Architektur-Sicht unsinnige Änderungen vorgenommen werden nur um Fremdmodule von der Zusammenarbeit auszuschliessen

Eine ähnliche Art von "Kooperation" scheint auch hier vorzuliegen. Dort wurde ja auch offensichtlich die (eigentlich sinnvolle) Funktionalität zunächst im KNX eingebaut. Aber anstatt diese Funktionalität in den Kern zu verschieben damit es alle Module auf gleiche Art verwenden können, wurde diese Funktionalität auf eine inkonsistente Art re-implementiert. BTW: Auf meine Nachfrage, was denn die TECHNISCHE Begründung ist, das im KNX-Modul unterzubringen und damit anderen Modulen vorzuenthalten bist Du leider nicht eingegangen... Das würde mich übrigens nach wie vor noch interessieren.

Kooperation kenne ich anders..

Aber immerhin hast Du offensichtlich mittlerweile eingesehen, dass initialized das falsche Kriterium für den scan ist

[GammaTwin]

Grüße,

würden wir in einer Firma zusammenarbeiten, würde ich folgendes vorschlagen:
Wir gehen zu dritt Mittagessen. Lockeres Gespräch, ein paar persönliche Interessen bereden. Dann gehen wir in einen Raum mit Whiteboards, Flipcharts. Wir reißen die aktuellen Struktur der Module auf und entwickeln ein paar Varianten.
Ich kann mir gut vorstellen, dass Ihr technisch auf Augenhöhe diskutiert und am Ende eine Lösung entsteht.

Geschriebene Kommunikation kann schnell falsch verstanden werden, weil der Ton (der die Musik macht) fehlt. Ich würde daher Sätze wie "Aber immerhin hast Du offensichtlich mittlerweile eingesehen" vermeiden.

[jw9]

Geschriebene Kommunikation kann schnell falsch verstanden werden, weil der Ton (der die Musik macht) fehlt. Ich würde daher Sätze wie "Aber immerhin hast Du offensichtlich mittlerweile eingesehen" vermeiden.

Mag sein, dass der Ton nicht ganz gepasst hat.

Nur aus Neugierde: Welche Formulierung hättest denn Du verwendet, wenn Du Dir (wie ich in diesem Thread) die Finger wund geschrieben hättest um zu begründen, dass INITIALIZED das falsche Kriterium ist und in der Folge dann die Zusammenarbeit des scan mit allem was nicht KNXIO ist komplett deaktiviert wird?

[GammaTwin]

Nur aus Neugierde: Welche Formulierung hättest denn Du verwendet

Ich muss gestehen, dass inhaltlich nicht folgen kann. Ich verstehe die Architektur der Module nicht.

Ich glaube verstanden zu haben, dass
- erwin sich etwas dabei gedacht hat und seine funktionierende Lösung in der cmd-ref entsprechend beschrieben hat.
- jw9 mit dieser Lösung einen Konflikt mit dem in Entwicklung befindlichen Modul hat
- jw9 in erwins Lösung einen "Architektur-Problem" sieht.
- erwin dieses Problem versteht
- erwin nach Veröffentlichung des Moduls von jw9 an einer gemeinsamen Lösung mitarbeiten würde

Wenn ich da völlig falsch liege, dann schon mal Entschuldigung.

Wenn Dir, jw9, aber vorerst nur die Aktualisierungsmöglichkeit des KNX_scan fehlt, hilft vielleicht mein Post #49 https://forum.fhem.de/index.php?msg=1194222. Darin habe ich den Scan als DOIF konstruiert.
Vielleicht ein workaround bis zur Veröffentlichung. Und dann könnt Ihr nochmal Eure Sichtweisen besprechen.

[erwin]

Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!

Re.: KNX_scan
KNX_scan (als FHEM cmd) ist jetzt in einem neuen Modul: 98_KNX_scan.pm untergebracht. Das entspricht nun den Architekturvogaben und ist daher auch in der cmd-ref unter FHEM commands zu finden und auch "help KNX_scan" ist jetzt verfügbar.

Die KNX_scan() perl funktion ist wieder im KNX-Modul untergebracht.
Nicht unterstützt ist die useage falls als IO-Modul TUL bzw. KNXTUL verwendet wird, weil diese beiden Module in bestimmten Situationen falsche/irreführende Fehlermeldungen auslösen, bzw. falsche Resultate liefern. Siehe: https://forum.fhem.de/index.php?topic=133667.0 post #1 und #3. Danke übrigens fürs finden!

Ich akzeptiere, dass nicht alle user von TUL/KNXTUL auf KNXIO umsteigen (never change a running system), andererseits erwarte ich die Akzeptanz, das neue Funktionalitäten, in diesem Fall "Hilfsfunktionen/Utilities/Goodies", nicht von allen bisherigen Modulen unterstützt werden, wenn es damit Probleme gibt.
Dass ich die betroffenen Module nicht ändern darf (bin nicht der Owner) und will, ist hinlänglich dokumentiert. Aber evtl. findet sich jemand, der die Verantwortung/den Support dafür übernehmen will.
Das ich mit meiner vorigen Änderung "Module in development" von der Funktion ausschließe, war mir zu dem Zeitpunkt weder bekannt noch bewußt und wird hiermit korrigiert. Von der Progammlogik / Wartbarkeit wär's zwar im IO-Modul besser aufgehoben, (wird zu 99% von einem <io-device>:xxxxx event aufgerufen), aber was solls...

PS: Meine Interpretation der Begriffe: supported / unterstützt:
-supported: cmd bzw. funktion sollte funktionieren, falls nicht ist das ein bug und wird gefixt, falls nicht möglich - als Einschränkung in der cmd-ref dokumentiert.
-not supported: kann funktionieren, muss aber nicht (in allen Situationen korrekt) funktionieren ! Kein fix, evtl. gibts einen "hack" / workaround.
Diese Definition ist nicht auf meinem Mist gewachsen, sie stammt, frei übersetzt u. gekürzt, von einem zahlungspflichtigen SW-Service Vertrag.

Als absolutes NOGO empfinde ich support posts, die basierend auf nicht aktueller Version oder lokal modifizierten Modulen gemacht werden ohne im selben post darauf explizit hinzuweisen, (noch besser: die Modifikation/Version# zu posten), weil damit ein nachvollziehen des Problems unmöglich wird.   
Etliche Rückfragen, "falsche Annahmen", Missverständnisse,... könnten vermieden werden, wenn man das [link]https://forum.fhem.de/index.php?topic=71806.0[/link] vor dem posten liest, und dadurch mit weniger Aufwand zu schnelleren/besseren Lösungen kommt.
l.g.erwin