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

[erwin]

Hi KNX Community!

Hauswart und ich haben versucht, etliche vorhandene Patches und auch einige weitere Korrekturen in das KNX Modul zu integrieren.
Nachdem sich bisher kein neuer "Owner" für das Modul findet, haben wir einen Weg gefunden, das überarbeitete Modul relativ simpel und automatisiert mit dem update Prozess zu verteilen.
Selbstverständlich gilt: verwenden auf eigene Gefahr!
Wie kommt ihr zu den Updates?
in der fhem cmd-line:

Code: [Auswählen]

update add https://raw.githubusercontent.com/erw111n/FHEM-KNX/main/controls_KNXevolution.txt
attr global exclude_from_update fhem.de.*:FHEM/10_KNX.pm
Die zweite Zeile verhindert ein überschreiben der "neuen 10_KNX.pm" mit der originalen!
Beim nächsten update wird die neue 10_KNX.pm heruntergeladen.
Beim FHEM start gibts möglicherweise eine Fehlermeldung: FHEM::Meta::__GetUpdatedata: ERROR: FHEM/10_KNX.pm belongs to ..., das müssen wir noch klären...
Die update history findet ihr unter:

Code: [Auswählen]

https://github.com/erw111n/FHEM-KNX/blob/main/updateHistory.txt
Ich ersuche in diesem thread nur Dinge zu posten, die mit dieser Version zu tun haben, also Fehler, die mit der originalen 10_KNX.pm nicht auftreten
und selbstverständlich auch Wünsche zur Erweiterung/Ergänzung.
Wir werden versuchen, das so gut wie möglich zu supporten. Danke jedenfalls an die Tester, die bisher mitgeholfen haben.

Update 17/08/2021 Eine neue Version: E04.66 steht zum download bereit. Es gibt nur wenige Änderungen im code, Details dazu:
https://github.com/erw111n/FHEM-KNX/blob/main/updateHistory.txt
bzw. hier:
https://forum.fhem.de/index.php/topic,116737.msg1170677.html#msg1170677

Um Feedback wird gebeten.....
l.g. erwin

l.g. Erwin

[JoeALLb]

Servus! Herzlichen Dank!!!

Nun, einen Wunsch habe ich schon!
Ich hätte gerne bei jedem DPT (wo möglich) analog zu "DPT1.000" den Zahlenwert als Reading, nicht nur "on/off/force".
Beim Scripten und beim Weiterleiten von externen Werten auf den KNX-Bus ist das immer etwas unangenehm und wird auch bald unübersichtlich.
Gerade zB DPT2 nutze ich immer mit 0,1,2,3 , so wie es meine Visu auch nutzt.

Ich würde also gerne DPT2.000 mit 0,1,2,3
   
sG Joe

[erwin]

Servus JoeALLb,

muß nachdenken: meinst du nur den numerischen Wert OHNE unit ?
dpt2 ist klar, welche noch?
wie soll die setlist bei dpt2.000 aussehen? wie dpt2 oder 0-3 ? Würde ungern beides zugleich in eine setlist aufnehmen....
 
dpt3,  dpt5, dpt6, dpt7, dpt8, dpt9, dpt13, dpt14 erfüllen deinen Wunsch bereits, wenn ich's richtig verstanden hab.

ich könnte dir kurzfristig einen patch basteln... es geht doch nur um %dpttypes variable, oder?

l.g. erwin

[Amenophis86]

Ich finde die Idee gut und bin dankbar, dass ihr das macht. Ich frage mich jedoch, ob es sinnvoll ist keinen klar erkennbaren Unterschied zur original Version zu haben. Wenn jemand nämlich ein Problem hat ist dann immer erstmal die Frage, ob er die aktuelle oder "eure" Version hat. Manch einer weiß das vielleicht irgendwann nicht mehr. Macht es nicht mehr Sinn eure Datei umzubenennen und diese parallel zur alten Laufen zu lassen? Es wäre immer noch keine offizielle Datei aber in jedem List etc würde man direkt sehen, dass es nicht die originale ist.

[erwin]

Hi Amenophis86,
der Gedanke ist mir auch schon gekommen, allerdings würde ein neuer Modul-name einen neuen Device-typen bedeuten....soll heissen es müsssten alle Definitionen neu erstellt werden. Das hatten wir schon mal bei EIB->KNX, war nicht soo lustig....
Für die nächste Version wird's eine Versions-kennung geben, erkennbar beim list <device>, damit ist eindeutig feststellbar was für eine version läuft.
l.g. erwin

[Amenophis86]

Mittels defmod und Platzhalter sehe ich da nicht so das Problem aber mit Versionskennung ist auch ne akzeptable Lösung denke ich.

[GammaTwin]

Daumen hoch

[GammaTwin]

Grüße,

ich habe folgendes Phänomen. Es wird kein "get" im FHEM mehr angeboten, siehe Bild.

Die Struktur ist bei mir oft "g1 set" und "g2 get".

Der Device dazu:

Code: [Auswählen]

defmod KNX_0400000 KNX 4/0/0:dpt1.001:g1:set:nosuffix 4/1/0:dpt1.001:g2:get:nosuffix
attr KNX_0400000 IODev KNX

[erwin]

Sorry, sehr dummer Fehler !!!

versuch noch mal ein update & restart!
l.g. erwin

[GammaTwin]

  geht

[JoeALLb]

sorry fürs nicht antworten, ich habe keine benachrichtigung erhalten, dass hier Text ergänzt wurde.

Mir würde 0-3 reichen, für skripting wäre das einfach toll.

Noch etwas, was ich häufiger benötige. Schon wäre, wenn ich an eine GA einen Wert senden könnte, ohne dass ich sie vorher als device anlegen muss.

so etwas wie
set knx dpt2 2

oder eben einen Temperatur Wert.

Bei mir wird die Gruppenadresse aus einem Parameter errechnet. Somit habe ich alles, was ich benötige, um den Wert auf den KNX Bus zu senden. Aber dass die weiß in fhem kenne ich nicht. Aktuell Behelfe ich mir, indem ich über die Kommandozeile KNXTools aufrufe.

[erwin]

HI JoeAllb !

zum Thema dpt2.000 schreib ich dir anschließend eine PN.

zum Thema senden ohne device namen:
die betreffenden GA's sind in FHEM (mit Namen / dptXXX) definiert?
   falls JA: es gibt eine Möglichkeit, den Namen (mittels perl-code) herauszufinden!   Dafür könnte ich ein Beispiel liefern.
   falls NEIN: das DEFMOD -temprorary cmd kennts du? Damit kannst du "dynamische Namen" vergeben( siehe autocreate ), die nicht in der config gespeichert werden.
Das Problem, das ich sehe, wenn gar keine def vorhanden ist, dann schlägt evtl. autocreate zu, bzw. es gibt "unknown code, pls help me..." messages...
l.g. erwin

[JoeALLb]

Danke für die Antwort! Ich habe viele GAs in komplexeren FHEM Devices zusammengefasst. doppelt anlegen von GAs hag Nachteile. Bin noch am überlegen, ob mir auch noch was besseres einfällt...

[erwin]

Hi,

doppelt anlegen von GAs hag Nachteile.

das brauchst du nicht, wichtig ist nur, dass es zumindest eine def für diese GA gibt!

folgender code (für die 99_myUtils.pm) könnte ein Anfang sein, wobei ich nicht weß, in welchen Format du die GA jetzt hast...

Code: [Auswählen]

#### tesst KNX sendig w.o knowing name, gadname
#### calling param: target (format: 11/2/33), value
###  e.g.: testknxsend('11/2/33','off')
sub testknxsend {
  my ($target,$value) = @_;

  my $gadCode = KNX_nameToHex($target); # convert to hex format

  if (!(exists $modules{KNX}{defptr}{$gadCode})) {
    Log3 undef,1, "testknxsend: undefined gadCode $gadCode";
    return;
  }

  ### following lines copied from KNX_parse ###
  my @deviceList = ();
  @deviceList = @{$modules{KNX}{defptr}{$gadCode}};

  Log3 undef,1, "testknxsend: Nr. devices found: " . scalar(@deviceList);

  foreach my $deviceHash (@deviceList) {
    #get details
    my $deviceName = $deviceHash->{NAME};
    my $gadName = $deviceHash->{GADTABLE}{$gadCode};

    Log3 undef,1, "testknxsend: set $deviceName $gadName $value";

    ### here we do the KNX_set
    my $res = KNX_Set($deviceHash,($gadName,$value));
    last; # exit on first hit
  }
  return;
}l.g. erwin

[JoeALLb]

Hallo Erwin,

vielen Dank! Sehr spannender Ansatz, ein erster Versuch funktioniert auch perfekt!
Ob das Anlegen aller KNX-GAs als Device nötig ist, überlege ich aktuell noch.
Es handelt sich dabei nei mir um grob 2000, die meisten davon sind für Temperatur
da, und als KNX-Device selbst benötige ich diese in FHEM nicht.
Die GA hole ich mir aus dem Device-NAmen des Temperatur-Devices, somit wäre ich eigentlich
völlig unabhängig von weiteren Devices wie eben dem KNX-Device.
Als Idee könnte ich dieses direkt in deinem Perl-Script mit anlegen, hier müsste ich abe rnochmal prüfen, ob das mit dem aktuellen
FHEM-KNX-Modul funktioniert, denn dort wurden in der vergangenheit nach jedem defmod auf ein KNX-Device die Events verdoppelt.

Ich beobachte es mal!

sG
Joe