Modul 10_KNX.pm - support

[jw9]

Ich akzeptiere, dass nicht alle user von TUL/KNXTUL auf KNXIO umsteigen (never change a running system),

Wie ich schon mehrfach erläutert hatte geht es nicht um "never change ..." sondern vielmehr darum, dass die Funktionalität (direkte Anbindung an KNX mittels TPUART) mit KNXIO nicht geht.

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.

Habe ich so auch nie erwartet.

Nach der Diskussion in diesem Thread hatte ich nicht den Eindruck, dass bei Dir die Bereitschaft gegeben ist, vom "INITIALIZED" als Kriterium abzurücken. Entsprechend hatte ich daraufhin einen eigenen scan implementiert.

Dann hattest Du den scan auf connect umgestellt, woraufhin ich meinen scan wieder ausgebaut hatte.

Nur um festzustellen, dass Du kurz darauf den scan verschoben und damit die Nutzung aus anderen Modulen heraus unterbunden hast.

Habe dann meinen scan wieder eingebaut und habe jetzt Ruhe. Der ist eh besser

Dass ich die betroffenen Module nicht ändern darf (bin nicht der Owner) und will,

Ist einsichtig. Hatte ich aber auch nie gefordert! Aktiv die Zusammenarbeit unterbinden ist aber auch nicht die feine englische Art, oder?

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

Das kann man durchaus differenzierter betrachten. Aber ich will an dieser Stelle nicht ein weiteres Fass aufmachen...

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.

Nach dieser Definition hatte ich weder um einen Fix noch um eine Änderung der Doku gebeten. Schon gar nicht im TUL-Modul. Verstehe also Deine Aufregung nicht wirklich.

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,

Hmmm... Welchen "support post" meinst Du damit genau?

Es ging mir auch nie darum, support für das TUL-Modul zu erhalten. Lediglich darum, dass die Zusammenarbeit nicht AKTIV unterbunden wird.

[baerm]

Hallo Erwin,
ich habe folgenden Fehlermeldungen, die ich früher nicht hatte:
2023.08.20 21:51:16 2: KNX_0005036 [KNX_encodeByDpt 1413]: gadName=g1 VALUE=Radio Wien - Sommer does not match allowed values: (?^msix:.{1,14})
2023.08.20 21:51:16 2: di_Display_Statustext2: set KNX_0005036 g1 Radio Wien - Sommer: "set KNX_0005036 g1 Radio Wien - Sommer" failed, see Log-Messages
Ist hier der String zu lange? Wie kann ich das lösen?
lg,
Matthias

[erwin]

Hi Matthias!
ich nehme an, das um einen dpt16.xxx geht,
und ja der string ist zu lang, hat 19 Zeichen, 14 sind das Maximum.
In diesem Bereich wurde schon lang nichts geändert...., in der nächsten Version werden UTF-8 (z.b. deutsche Sonderzeichen (ÄÜÖß...) besser unterstützt werden. Allerdings nur für dpt16.001, im ASCII gibts die nicht!

Wie kann ich das lösen?

Wenn ich wüsste, wie der String entsteht, würde ich folgendes vorschlagen:

Code Auswählen Erweitern

my $newstring = substr($string,0,14);
fhem("set KNX_0005036 g1 $newstring"); l.g. erwin

[baerm]

Hi Erwin,
also die Einträge tauchen bei mir in den Logs "fhem-2023-07.log" erst seit Juli auf und der Wert wird an den Bus nicht mehr übergeben. Das war bis jetzt aber immer der Fall.
Setzen tue ich den Wert mittels DOIF:

Code Auswählen Erweitern

set KNX_0005036 g1 [CR_755_Radio] - [KNX_0104055]lg,
Matthias

[erwin]

Hi Matthias,
OK, das mit den Meldungen glaube ich dir ja, und geändert wurde in dem Bereich (ich hab bis April 2023 gecheckt) nichts, ausser dieser zusätzlichen Log-Msg!
Tatsache ist, dein string ist zu lang (19 Zeichen), im Standard definiert sind max. 14 Zeichen.
Nachdem ich selbst kein Text-display hab, hab ich mir ein Datenblatt von MDT geholt, da steht folgendes:

Der Glastaster II Smart mit Temperatursensor ....  Weiterhin können benutzerdefinierte 1 Bit Meldungen und
14 Byte Texttelegramme angezeigt werden.

die Frage: welches display hast du?
Stand jetzt: falls ein set auf ein dpt16 kommt, länger als 14 Zeichen, wird es verworfen.- nix an den Bus gesendet!
Mögliche Lösungen:
1) du limitierst dein set... auf 14 Zeichen. - beim doif kann ich dir allerdings überhaupt nicht helfen...
2) ich könnte im Modul den Text ab dem 15. Zeichen abschneiden und den Rest an den bus senden
   gefällt mir eigentlich gar nicht, verfälscht den Willen des Users, und eine Log msg müsste ich dennoch erzeugen...
l.g.erwin

[baerm]

Hallo Erwin,
ja, ich verwende genau diesen Glastastertyp und der String ist auf 14 Zeichen begrenzt.
Mein System ist schon sehr gewachsen und mit der großen Zahl der DOIFs auch schon recht unübersichtlich.
Ich bin daher immer dankbar, wenn etwas einfach funktioniert und ich nicht immer Zusatzfunktionen oder Userreading erstellen müßte. FHEM ist super flexibel aber auch leider manchmal nicht sehr userfreundlich. Das System soll mir das Leben doch erleichtern und mich nicht Stundenlang beschäftigen 
Ich verstehe natürlich auch Deine Philosphie, dass der Code nicht mehr als notwendig eingreifen sollte und der User wissen sollte was er tut.
Ich werde mir eventuell meine Myutil erweitern.
lg,
Matthias



 

[erwin]

Hi Matthias,
was ich nicht weiß: Wie verhält sich das Display, wenn mehr als 14 Zeichen ankommen? .. kommt irgendwas an, oder werden die ersten oder letzten 14 Zeichen angezeigt???
Um das testen zu können, wird es in der nächsten Version einen "dptRAW" geben, der beliebig lange hex-strings an das device schickt, bzw. auch empfängt und als reading darstellt.
um z.b den string 'abcdefghij' zu schicken, schreibt man:

Code Auswählen Erweitern

set <device> <gadName> 006162636465666768696a00verfügbar vmtl. ab nächster Woche...
Abhängig von den Ergebnissen dieser Tests, werde ich mir überlegen Option 2 zu implementieren.
l.g.erwin

[baerm]

Hi Erwin,
bis jetzt wurden die Strings angezeigt und vom Display abgeschnitten. Das war auch ok für mich. Nur seit dem ich diese Fehlermeldung bekomme, wird nichts mehr geschickt und damit auch gar kein Update am Taster angezeigt.

Beim set Befehl geht natürlich auch nichts durch....

Code Auswählen Erweitern

2023.08.24 14:43:32 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at /opt/fhem/FHEM/92_FileLog.pm line 942.
2023.08.24 14:43:46 2: KNX_0005036 [KNX_encodeByDpt 1413]: gadName=g1 VALUE=006162636465666768696a00 does not match allowed values: (?^msix:.{1,14})
2023.08.24 14:43:50 1: LOG: WPM set 52.
Damit kann ich das so nicht testen.
lg,
Matthias

[erwin]

Hi Matthias!

das kannst du auch NOCH NICHT testen, dazu brauchst du den dptRAW, den es erst ab nächster Woche gibt....

bis jetzt wurden die Strings angezeigt und vom Display abgeschnitten. Das war auch ok für mich.....

Ich habe mich entschlossen, den dpt16 so wie in OPT 2 beschrieben zu ändern, in der Version von nächster Woche.
Test läuft...
l.g. Erwin

[erwin]

Hi KNX_Community!
Neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
Viele changes bei dpt range,units, neue sub dpt's , ich habe ein "neues" dpt standard document (2021) gefunden, das bisherige war aus 2013!

NEU: dptRAW - erlaubt beliebige hex strings zu senden/empfangen, die KNX-Hardware muss das natürlich auswerten können! Beispiele: siehe cmdref . Ist gedacht für Entwickler von KNX-HW-devices....

@Matthias, du brauchst nicht testen, dpt16 sollte jetzt so funktionieren, es wird auf Länge 14char abgeschnitten + Log-msg.
@Amenophis86, der dpt251.600 ist jetzt unterstützt.
l.g.erwin

[Amenophis86]

Guten Morgen,

Danke für die Änderungen.

Ich hätte noch eine Frage. Unterscheidet FHEM zwischen GroupValueWrite und GroupValueResponse oder wird bei beiden ein Event generiert? Ich tippe auf beide.

Hintergrund ist, dass ich aktuell mit Home Assistent ein bisschen teste. Hier werden die Daten regelmäßig abgefragt, was dazu führt, das FHEM mir Push Nachrichten schickt, obwohl der Status sich gar nicht gebändert hat. Dies kann ich aber auch mit event-on-change-reading nicht abfangen, da ich teilweise bei manchen Dingen bei jedem Trigger senden muss.

Da ich, wenn überhaupt, beide Systeme parallel betreiben werde, muss ich mir hier etwas überlegen und dazu will ich erstmal die Gründe verstehen

[erwin]

Hi Amenophis86,

Unterscheidet FHEM zwischen GroupValueWrite und GroupValueResponse oder wird bei beiden ein Event generiert?

Du meinst bei einer msg Richtung KNX-Bus->FHEM ? Nein, wird nicht unterschieden, beide werden in "getreading" kopiert. Event wird ausgelöst, abhängig von event-on-xxx.
Ein GroupValueRead Richtung KNX-Bus->FHEM wird über das Attr. putCmd gesteuert...
Ich verstehe nicht, warum HA regelmäßig den Bus abfragt, ist in einem KNX-system kontraproduktiv, sowas kann man mittels ETS-Parameter (z.b. intervall, Value change, Value threshold,...) in den meisten KNX devices festlegen.
Gutes Beispiel ist mein Windsensor: mittels ETS definiert:
1) sende Windspeed, min intervall 5 sekunden UND Wert Änderung > 5%.
2) sende Max/Min Windspeed jede Minute.

Update: einem GroupValueResponse geht immer ein GroupValueRead voraus, (wo immer der ausgelöst wird), FHEM kann das nicht unterscheiden ob selbst "verursacht" (mit get-cmd) oder von einem beliebigen anderen Bus-Teilnehmer. Im Endeffekt ist es gleichgültig, ob ein Write oder Response ankommt, es ist immer ein "status" vom device.

l.g.erwin

[Amenophis86]

Hallo erwin,
HA scheint zu unterscheiden, ob ein Response oder Write vorliegt. Ein Response ist quasi kein neues Auslösen eines Events, sondern nur ein bestätigen des aktuellen Zustandes. Ein Write ist ein neues Event. Ich kann diese Logik nachvollziehen und frage mich, ob es nicht sinnvoll wäre auch in FHEM eine Unterscheidung herbei zuführen? Beispiel, wenn ich mit get abfrage, dann will ich auch nicht immer, dass das Event ausgelöst wird, sondern manchmal verpasst FHEM zB bei mir ein Event. Dies kann sein, weil ich den knxd deaktivieren muss, wenn ich eine neue PA vergebe oder FHEM für ein Update neustarten musste etc.

Warum HA die Zustände regelmäßig abfragt habe ich auch noch nicht ganz verstanden, aber vermutlich um sicherzustellen, dass kein Event verpasst wurde. Bei einer Unterscheidung zwischen Response und Write ist das ja auch nicht schlimm.

Mir ging es in erster Linie darum es zu verstehen und das habe ich nun. Jetzt muss ich überlegen, wie ich damit umgehe

[erwin]

Hi,
evtl. nomals zur Klärung:
in FHEM werden die entsprechenden readings IMMER mit jeder empfangenen msg upgedatet, der nachfolgende Event (gesteuert über die event-on-xx Attr's) hat nur den Sinn:
1) in der GUI die reading Zeile dynamisch upzudaten (und rot einfärben....)
2) FileLog / DbLog auszulösen.
3) notify/doif/... auszulösen.
4) evtl. auch noch andere Module auszulösen, die diese events subscribed haben... (e.g. MQTT)...
.. das ist jetzt überhaupt nicht KNX-spezifisch, das ist FHEM core Funktion.
FHEM-KNX spezifisch ist, das GroupValueWrite und GroupValueResponse beide im "get-reading" landen.
... Wobei ich beim Empfang einer GroupValueResponse message keine Möglichkeit habe festzustellen, wodurch diese ausgelöst wurde! (FHEM get-cmd oder v. anderem system GroupValueRead)
l.g.erwin

[Amenophis86]

Wir reden glaube leicht aneinander vorbei

Mir ist sowohl klar, wie FHEM mit event-on... etc arbeitet als auch, wie KNX arbeitet. Die Frage, welche sich mir stellt ist, ob die Zusammenarbeit so 100% korrekt ist, wie es im Moment ist. Ich gebe dir ein einfaches Beispiel:

Ich öffne die ETS und frage den Zustand über eine GA mittels "Wert lesen" ab. Was ich bekomme ist ein GroupValueResponse und kein GroupValueWrite. Warum gibt es Unterschiede? Weil KNX klar sagt, ich kann auch den Zustand abfragen wollen ohne, dass andere Geräte darauf reagieren. Gleiches gibt es in FHEM, in dem ich mittels event-on-change und event-on-update arbeite. Problem ist, dass FHEM im Moment zwischen GroupValueWrite und GroupValueResponse nicht unterscheidet. Das heißt, wenn ich mittels ETS einen Zustand abfrage, dann wird bei FHEM automatisch ein Event getriggert.

Es stellt sich damit für mich die Frage, kann man an der Übergabestelle zwischen FHEM und KNX unterscheiden, welche Art von Antwort vom KNX BUS kommen? Wenn ja, dann könnte man vermutlich programmieren, dass ein GroupValueResponse standardmäßig kein Event triggert in FHEM, sondern ein Reading nur auf den aktuellen Stand bringt und ein GroupValueWrite das Reading auf den aktuellen Stand bringt und auch ein Event triggert. Das ist alles worum es mir geht