[obsolet - Modul ist im SVN - siehe Forum #12582] 10_KNX.pm Weiterentwicklung

[lichtimc]

Ja, hast recht, wäre eine gute Möglichkeit.
Noch ein Gedanke: Die Idee mit dem jeweils neuesten Reading (egal ob getGx oder setGx oder switch-set oder switch-get oder ...) als Status für toggle zu nehmen: würde das nicht dieses Attr ersparen und das selbe Resultat bringen?

Achso, nein denn dann gibts Probleme mit bspw. meinen dimmbaren Lampen, die haben nicht nur dpt1 sondern auch dpt5 GAs drin.
Also attr ist wirklich die beste Möglichkeit.

[erwin]

Hi,
erstmal danke für die lebhafte diskussion!

1) Fakt ist: in der SVN Version wird der aktuelle status vom get-reading geholt.
- ein fhem set g1 toggle set in jeden Fall ein set-reading.
- aber falls die set option in der def gesetzt ist, wird KEIN get-reading gesetzt. Das verhindert u.a., dass FHEM-Web UI ein Get xxx anbietet.
- ein set reading für diese GA wird allerdings auch gesetzt, wenn vom KNX-Bus (z.b. ein Taster) diese GA ausgelöst wird.  Insofern wäre das set reading das richtige,
  ( ein fhem cmd "get xxx Toggle ..." gibts nicht), und der aktuelle status wäre korrekt. (in diesem punkt war mein post v. gestern falsch)
- das würde für die Lösung mit dem set-reading sprechen.
- die Feedback GA's wurde bisher nie ausgewertet, wär auch extrem komplex, müsste man alle $defs durchsuchen, und eigentlich fällt mir nichts dazu ein, wie ich automatisch feststellen könnte, was die feedback GA zu dem TOGGLE ist.
Ergibt: wenn keine set-Option in der GA gesetzt ist, ist set-gx gleich get-gx. Falls :noSuffix-option gesetzt ist: ebenso. (wäre jetzt ein temp. fix!)
2) seltsame Dinge: es gibt knxd-versionen, die senden grundsätzliche ein echo auf alles was von FHEM kommt, und andere versionen bzw. KNX-GW's die machen das nicht! da wird einmal get-xx befüllt, oder nicht! Das KNXTUL_Modul (Multicast) macht das schon aus FHEM heraus so! Dort könnte man das abstellen, ist aber ein Eingriff ins KNXTUL Modul. Ob es fürs TUL Modul das auch gibt, hab ich noch nicht recherchiert. Fürchte eher nicht, ist standard TCP/IP - und das echo komm/kommt nicht von knxd. 
3) state fällt als option weg, wär zwar super einfach, weil (im Normalfall) alle reading dort aufschlagen und immer das letzte im state steht, aber was wär zu tun wenn dort einmal 55% steht, weil ein Rollladen ca. in der Mitte steht? Und dann noch stateRegex (das hat bei mir noch nie so funkt. wie ich wollte, muß ich mir mal in Ruhe anschauen, alles was ich versucht hab hat böse Seiteneffekte, oder ich bin zu ... dazu!) und stateCmd, stateFormat... Zu viele Variablen!
4) für devices, die eine Rückmeldung GA haben, setze ich stateformat auf get-xx der Rückmeldung, damit hab ich im state immer den aktuellen/richtigen wert und kann mit devstateIcon immer das richtige Kommando auslösen. ->kein toggle!
5) Vorschlag via Attr: ist eindeutig die sauberste Lösung, allerdings programmtechnisch muss ich da noch Vorarbeiten dazu machen: Stichwort: Zugriff auf Attribute während FHEM-Start. Ein default wär sinnvoll, welcher ist noch die Frage .

mein Vorschlag für die Version v. nächster Woche: TOGGLE bleibt wie in der SVN version, temp fix für Gertäte, die keine Rückmeldung haben:

Code Auswählen Erweitern

define <device> KNX dpt1:g1:nosuffix
... oder
define <device> KNX dpt1
... also auf set-option verzichten 
bin gespannt auf FB
l.g.erwin

[lichtimc]

Bei mir wird das setG1 Reading nur gesetzt, wenn der Befehl aus FHEM kommt. Wenn ein Taster auf die gleiche Gruppenadresse schickt, dann erscheint das im FHEM bei mir unter getG1.
So konnte ich mir super Sachen programmieren wie folgendes:

Meine sämtlichen Lichter im Haus werden mittels Bewegungsmelder geschalten, aber nicht mit direkt verknüpften GAs Melder<-->Licht sondern über ein DOIF im FHEM. (=viel mehr Flexibilität)
Wenn nun aber der Server ausfallen sollte (und ich bin nicht daheim hat meine Frau immer noch die Möglichkeit, die Lichter über die Taster am Schalter zu bedienen. Bei laufendem Server dient der Schalter dann nur dazu um, falls mal notwendig, einen Bewegungsmelder zu sperren.

Dies erreiche ich durch die Unterscheidung zwischen getG1 und setG1 und deshalb stimmt diese Aussage (bei mir) gottseidank nicht:

- ein set reading für diese GA wird allerdings auch gesetzt, wenn vom KNX-Bus (z.b. ein Taster) diese GA ausgelöst wird.  Insofern wäre das set reading das richtige,
  ( ein fhem cmd "get xxx Toggle ..." gibts nicht), und der aktuelle status wäre korrekt. (in diesem punkt war mein post v. gestern falsch)

Vielleicht hat es was mit den "seltsamen Dingen" zu tun!?

[Amenophis86]

Ich kann es gerade nicht testen, da unterwegs aber ich meine auch, dass bei einer Meldung von KNX bei mir nur das get Reading geändert wird und nicht das Set Reading aber müsste ich die Tage bei mir nochmal testen.

[erwin]

Ich hab jetzt nochmal drüber nachgedacht, wie ich (bis zur implementierung des Attribut gesteuerten TOGGLE) vermeiden kann, dass einerseits ein get-xx berücksichtigt wird und andererseits das set ebenfalls....

Die Lösung ist mir nach dem schreiben meines letzten Beitrages gekommen:
kurz skizziert:
- es gibst ein get-xx reading -> das wird verwendet.
- es gibt KEIN get-xx reading -> das set-xx wird als Basis genommen.

Damit sind wir einerseits rückwärtskompatibel und andererseits ist das Problem der set-option im define auch weg!
Ich hab kurz getestet, scheint zu funktionieren! Meinungen dazu?
l.g. erwin

[lichtimc]

Hört sich gut an. 
Und wenn es mehrere get-Readings gibt nimmt er das erste?

Also wenn etwas so definiert ist:

Code Auswählen Erweitern

define devicex KNX 1/2/1:dpt1:switch 1/2/2:dpt1:switchstate:get
... dann würde er immer das switch-get nehmen, wenn vorhanden, und sonst das switchstate-get oder wie würde das funktionieren?

[erwin]

Und wenn es mehrere get-Readings gibt nimmt er das erste?

Nein, er nimmt immer das reading, das zum set-cmd gehört! Das geht auch gar nicht anders, fhem kann nicht wissen, welches GA das Feeback GA ist!
Zu deinem Beispiel:
"set devicex switch toogle"  - holt den status aus dem reading "switch-get" ODER wenn das undefiniert/leer ist dann aus "switch-set".
Aus einem anderen reading (or anderen device:reading) den state zu holen war bisher nicht vorgesehen, das würde erst mit der Attribut-Lösung gehen.

In deinem Fall hast du allerdings in der GA:switchstate ohnehin immer den "korrekten" Status!
ich würde "stateFormat switchstate" verwenden, dann hast du im state den korrekten status. Mit devstateIcon kannst du dann das Lämpchen weiss oder rot anmalen und durch draufklicken "toggeln". (ist kein togglen, ist on/off).
Ein Beispiel von mir:

Code Auswählen Erweitern

Internals:
   DEF        5/2/88:dpt1:set 5/2/93:dpt1:get
   DEVNAME    Kinderzimmer_1_Schreibtisch
   Eversion   E04.20 10-01-2021
   FIRSTGADNAME g1
   FUUID      5c7ceaf9-f33f-5c4d-9e95-ef1801c53669be48
   GETSTRING  g2:noArg
   IODev      myKNXD
   NAME       Kinderzimmer_1_Schreibtisch
   NOTIFYDEV  global,TYPE=KNX
   NR         77
   NTFY_ORDER 50-Kinderzimmer_1_Schreibtisch
   SETSTRING  on:noArg off:noArg g1:off,on
   STATE      off
   TYPE       KNX
   GADDETAILS:
     g1:
       CODE       05258
       GROUP      5/2/88
       MODEL      dpt1
       NO         1
       OPTION     set
       RDNAMEGET 
       RDNAMEPUT  putG1
       RDNAMESET  setG1
       SETLIST    :off,on
     g2:
       CODE       0525d
       GROUP      5/2/93
       MODEL      dpt1
       NO         2
       OPTION     get
       RDNAMEGET  getG2
       RDNAMEPUT  putG2
       RDNAMESET 
       SETLIST    :off,on
   GADTABLE:
     05258      g1
     0525d      g2
   READINGS:
     2021-02-05 12:10:11   getG1           off
     2021-02-05 12:10:11   getG2           off
     2021-02-05 12:10:11   last-sender     0.1.80
     2021-02-05 12:10:11   setG1           off
     2021-02-05 12:10:11   state           off
Attributes:
   DbLogExclude last-sender
   IODev      myKNXD
   devStateIcon off:li_wht_off:on on:li_wht_on:off
   stateFormat getG2
   webCmd     :
... und das on/off Kommando geht (aus diesem Bespiel) immer auf die erste definierte GA
Also: set devicex on -> wird IMMER übersetzt -> set devicex g1/gadname on -
ein "set devicex switchstate on" -> würde auf die 2te definition gehen, wird aber verweigert, da get gesetzt ist! (was in diesem Fall absolut Sinn macht)
und übrigens: "TOGGLE" geht nur für dpt1 und dpt1.001 - seit immer schon.
l.g. erwin

[Amenophis86]

Hört sich gut an mit get bzw set.

[lichtimc]

Hi Erwin,
ich nehme an, du bist noch nicht dazugekommen, die neue Verson einzuchecken? Nicht dass ich beim Updaten was falsch mache...
Danke, lg

[erwin]

Nein, noch nicht....
hab heute noch einen bösartigen bug entdeckt - der schon in der "original-version" drin ist....
in Kürze: jedesmal wenn man eine definition (z.b. mit defmod) geändert hat, wurde aus einem Event  zwei, immer um einen mehr pro defmod, weil die alten internen strukturen nicht gelöscht wurden! Das ist erst mit einen FHEM Neustart wieder weggegangen.
das muss ich nochmal ordentlich testen...
l.g erwin

[Amenophis86]

Oh man, das erklärt warum bei mir manche Geräte auf einmal das Event so oft gefeuert haben. Ich hab mich schon gewundert. Danke fürs Auflösen

[erwin]

so die nächste Version 04.40 ist am Git. Viele Änderungen, bitte ausführlich testen.

@Amenophis86,
aufgefallen ist mir das beim Testen, und dann hab ich 2 Stunden erfolglos den Fehler im TUL-Modul gesucht! Das ist Selbstbewusstsein! 
l.g. erwin

[Amenophis86]

Das ist Selbstbewusstsein! 

Hast ihn ja gefunden und konntest über deinen Schatten springen

[GammaTwin]

Ich habe Schwierigkeiten seit dem Update. DOIF funktionieren nicht mehr, da es neues Readings gibt.

Meine typische Definition:

Code Auswählen Erweitern

1/1/0:dpt1.001:g1:set:nosuffix 1/2/0:dpt1.001:g2:get:nosuffix

Vor dem Update entstanden nur die Readings "g1" und "g2" (und last-sender). Jetzt entsteht auch "set-G1" und "get-G2".

Es scheint daran zu liegen, dass ich die Readings "g1" und nicht "schalten" genannt habe.

@erwin: kannst Du das nachstellen. Und wie gehen wir damit um?

[erwin]

Hi GammaTwin,

ja, konnte ich nachstellen, Problem war, dass ich bei der auswahl zwischen setGx und gad-Namen auf "gx" selektiert hab...
fix ist am GIT.
Sorry, du musst die falsch erstellten  readings löschen...
l.g. erwin