Modul 10_KNX.pm - support

[erwin]

Hi,

...Weil KNX klar sagt, ich kann auch den Zustand abfragen wollen ohne, dass andere Geräte darauf reagieren

Ja das stimmt natürlich, allerdings ist FHEM kein KNX-Gerät, sondern (in KNX-Terminologie) ein Monitor, der grundsätzlich jede GA in irgendeiner Weise verarbeitet bzw. darstellt.
Dein ETS-Beispiel bezieht sich offensichtlich auf den ETS-Group-Monitor, der exakt gleich funktioniert wie FHEM. Alles was vom Bus kommt, wird dargestellt, unabhängig davon wer das ausgelöst hat.

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

.
Ja das könnte man, die Konsequenz wäre allerdings, das auch ein "fhem get ..." , (das ja ein  GroupValueRead schickt und damit im Gerät ein GroupValueResponse auslöst), keinen EVENT auslösen würde.
Mir ist mom. nicht klar, wie ich das lösen könnte:
selbst wenn ich separate readings für GroupValueWrite und GroupValueResponse einführen würde, mit unterschiedlichen Handling der Events, würde das nichts an deinem Issue , bzw. an der Problematik von "fhem get ..." ändern.

...ich beim Empfang einer GroupValueResponse message keine Möglichkeit habe festzustellen, wodurch diese ausgelöst wurde! (FHEM get-cmd oder v. anderem system GroupValueRead)

Der Empang KNX-> FHEM läuft völlig asyncron!

PS: sehr, sehr "schräge Option": mittels eventMap/stateCmd auf <gadName> reagieren, nachschauen ob in den letzen x Sekunden ein "get <device> <gadName> von FHEM ausgelöst wurde. Falls JA-> event, falls NEIN->kein event.
... ungetestet weil noch nicht programmiert ...
l.g. erwin

[Amenophis86]

Ich mache mir auch nochmal Gedanken dazu. Wie gesagt ist es mir die Tage erst aufgefallen auf Grund der Home Assistent Thematik.

[baerm]

Hallo Erwin,
vielen Dank für die Änderung. Funktioniert super!
lg,
Matthias

[erwin]

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

l.g. erwin
@ Amenophis86: du hast pm.

[erwin]

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

l.g. erwin

[StefanG]

Hi Erwin,

auch hier noch ein kurzer Beitrag von mir:

Habe gesehen, dass einige dpt´s aus der ETS nicht in FHEM konfiguriert werden können, z.B. gibt der "STEINEL True Presence Multisensor" den Luftdruck in Pa als dpt14.058 aus. Lässt sich das bei Gelegenheit noch ergänzen?

Danke jedenfalls!

LG
Stefan

[erwin]

Hi Stefan,
kein Problem, wird in der nächsten Version drin sein.
Inzwischen kann man sich damit behelfen: Wiki
l.g. erwin

[erwin]

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

l.g. erwin

[StefanG]

Hi Erwin,

danke! Werde ich testen.

Mit der alten Version habe ich heute noch folgende Fehlermeldung bekommen:

Code Auswählen Erweitern

2023.12.28 07:08:29.022 3: Statustext5 [KNX_encodeByDpt 1528]: gadName= status modified by limits... Input= 05 Output= 05 Model= dpt16

Die Events dazu waren:

Code Auswählen Erweitern

2023-12-28_07:08:29 Statustext5 last-sender: fhem
2023-12-28_07:08:29 Statustext5 status-set: 05
2023-12-28_07:08:29 Statustext5 05

Die Definition (von soeben) ist:

Code Auswählen Erweitern

Internals:
  DEF        9/0/7:dpt16:status
  FUUID      6483aaa4-f33f-d238-a693-84de97d117188320
  IODev      KNXD
  NAME      Statustext5
  NR        214
  STATE      HarmonyBuero a
  TYPE      KNX
  eventCount 13978
  model      dpt16
  GADDETAILS:
    status:
      CODE      09007
      MODEL      dpt16
      NO        1
      OPTION   
      RDNAMEGET  status-get
      RDNAMESET  status-set
      SETLIST    :multiple,>CLR<
  GADTABLE:
    09007      status
  READINGS:
    2023-12-28 01:13:06  IODev          KNXD
    2023-12-28 10:28:40  last-sender    fhem
    2023-12-28 10:28:40  state          HarmonyBuero a
    2023-12-28 10:28:40  status-set      HarmonyBuero a
Attributes:
  group      KNX
  room      KNX

Kann es sein, dass das bei einem Text (dpt16) kommt, wenn die Textnachricht rein numerisch ist (05)? Welche Aussage hat die Meldung?

LG
Stefan

[StefanG]

Hi Erwin,

dpt14.058 wird akzeptiert jetzt, auch die dpt16-Meldung von oben ist weg in der neuen Version. Alles gut, danke!

LG
Stefan

[gero112233]

Hallo,

ich habe mit dem Datentyp dpt14 meine Probleme: ich kann keine Negative Zahl schreiben.

im Log bekomme ich folgende Meldung:
<device> [KNX_limit 1476]: cmd value modified by limits... Input= -2 Output= -1.4e-45 Model= dpt14

Ursache ist die Definition von MIN=>-1.4e-45: das ist -0.00000000...001.
Praktisch ist also jede negative Zahl zu klein (kleiner als -0,000...0001).

Müsste es nicht eher MIN=>-1.7e38 lauten?

Ich verwende das originale 10_KNX.pm:
# $Id: 10_KNX.pm 28207 2023-11-25 18:06:19Z erwin $


Beste Grüße,
Gero

[erwin]

Hi Gero,
du hast recht, dein Vorschlag ist korrekt!
Ich muss noch ein paar andere Modifikationen testen, fix ab morgen im SVN!
l.g. & danke erwin

[erwin]

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

l.g. erwin

[erwin]

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

l.g. erwin

[erwin]

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

l.g. erwin