FHEM Forum

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:
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:
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 (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

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

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

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.

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

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

Daumen hoch :)

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

Sorry, sehr dummer Fehler !!!

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

 :) geht

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.

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

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

Hi,

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

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

Hallo Erwin,

das Synchron halten zwischen KNXD Device und GAD bei dieser Anzahl an (dynamischen) Sensoren schaffe ich nicht.
Auch wenn deine Lösung toll ist und gut funktioniert, so bleibe ich doch lieber
bei meiner alten Variante.
{system("knxtool groupwrite ip:1.2.3.4 $gad $hexval &")}

könnte man nicht (irgendwann) dafür eine Möglichkeit ins Modul mit aufnehmen? Denn dort verwalte ich so etwas wie die IP-Adresse zentral.
Vielleicht wäre
"set knxDevice sendRaw xx" eine Idee/Möglichkeit? Allerdings müsste man hier zuvor den Wert noch nach HEX konvertieren.
Wäre das bei dem Aufruf über das KNX-Device auch nötig? Wenn JA, vielleicht könnte man im KNX-Modul die
"functions" zum Konvertieren von Werten in die jeweiligen DPTs auch auf global setzen, damit man sie in Userreadings, etc. nutzen kann?

Das sind nur so meine Ideen, wenn sie gar nicht passen, bitte ich jetzt schon um entschuldigung ;-)

sG
Joe

Hallo Joe,

irgendwie fehlen mir die Zusammenhänge von deinem setup.

Ich versuch mal, was ich verstanden hab:
1) du hast in fhem jede Menge Temperatur- und andere -devices unabhängig von KNX.
2) mit dem KNXtool groupswrite sendest du an ip / gadName einen Wert, Ip und gadName rechnest du aus dem devicenamen aus.
   was ich hier nicht versteh: was bewirkt das groupswrite in den devices, Antwort bekommst du ja keine darauf - (ausser "OK").
Bei 2000 Devices würd ich mir grundsätzlich überlegen, die Abfragen / das Management von ausserhalb fhem zu machen und nur die relevanten daten an fhem zu schicken- z.b mittels MQTT.

Das Problem an deinen vorschlägen ist, dass sämtliche send/receive/convert routinen auf interne daten-strukturen zugreifen, die mittels der KNX device definition erzeugt werden. das gehts nicht nur um dpt## !
An Empfang ist mit dieser Logik gar nicht zu denken, weil z. B. die fhem.pl (select)  und das TUL Modul ohne einer device definition nicht wissen können, wohin sie das packet schicken sollen....
l.g. erwin

Hallo Erwin,

ich bin dir echt dankbar für dein Engagement hier, schon dass sich bei knx in fhem etwas tut.


du hast das korrekt verstanden. Ich benötige das nur zum Senden! FHEM sammelt die deaamten Temperaturwerte zusammen, prüft diese mittels event-on. * um das datenaufkommen zu reduzieren und sendet diese auf den  KNX Bus. Dort benötige ich sie auch. Zahlreiche heizungsaktoren Mischer und Stellantrieb regeln damit die gesamte Hütte.
Das mit der Kommandozeile im userreading funktioniert ja auch und kann daher vermutlich beibehalten werden. Mir wäre lediglich das direkte Verarbeiten in fhem selbst lieber gewesen.

Rückmeldung benötige ich keine. Auf knx Seite läuft ein watchdog und schlägt Alarm, wenn ein sensor über 10 Minuten keine Werte mehr liefert. Somit kann ich im schlimmsten Fall sogar fhem automatisiert neu starten.
(es gab da mal ein memory leak).

edit:
KFHEM führt dabei eben Kabel gebundene Sensoren mit Funksensoren und proprietären von einzelnen Herstellern (Poolsteuerung, etc) zusammen und ermöglicht mir, diese am KNX zu nutzen.

Sg Joe

Hallo Joe,

KFHEM sagt mir jetzt überhaupt nix, ist aber auch egal....

Meine Ideen dazu:
1) so lassen, wie's ist, evtl. statt userreadings ein notify definieren, dass auf alle sensoren triggert, und dort das KNXtool aufrufen = ein notify für alle sensoren!
2) die variante mit defmod, ein KNX-Device für alle sensoren, dass jeweils vor dem set mit defmod auf den richtigen gadNamen/model gestellt wird.
    Das wäre mit etwas nachdenken durchaus in meinem Example-code noch unterzubringen.... - get sinnvollerweise auch nur mit notify wie in variante 1.

würde fast zu Var1 tendieren - ist Geschmackssache.
l.g. erwin

Mir ist gerade ein Fehler in der CommandRef aufgefallen. Dies betrifft zwar die alte KNX.pm aber vielleicht könnte man es dort anpassen oder zumindest bei der her berücksichtigen, wenn die mal offiziell werden sollte.

Unter Common attributes sind die Links von attributesExclude und cmdIcon falsch, da diese auf alias verweisen.

Hi,

danke für den Hinweis, habs in der neuen Version gefixt, die geht vmtl. Anfang nächster Woche aufs git...
l.g. erwin

update:
???? attributesExclude  ?????
..find ich nirgends sonst, ist das eine attribut-Leiche?

Guten morgen,
ich habe meinen FHEM Server (auf einem Raspberry) auf Buster umgezogen. Da dachte ich mir ich teste mal diese weiterentwickelte 10_KNX.pm. Also wie im ersten Eintrag die beiden Befehle ausgeführt und es geht auch alles.
Jetzt habe ich aber noch einen neuen Binäreingang und einen Aktor über die ETS Programmiert.
Ich drücke auf einen Taster und der Aktor schaltet einen Lüfter ein. Das funktioniert.
Wert setzen über die ETS funktioniert.
In FHEM sehe ich aber nicht wenn ich den Taster drücke sondern nur wenn ich den Wert über die ETS setze.
Beim Taster wie auch beim setzen des Wertes über die ETS geht der Lüfter an oder aus also wird es auch auf den KNX BUs gesendet.
Also habe ich eine alter Speicherkarte mit dem alten FHEM server gestartet. Dort sehe ich der Werte im Event monitor.
Es liegt also irgendwie an dem neu aufgesetzten FHEM Server.
Komisch ist auch das alle anderen KNX Geräte funktionieren (status wird in FHEM richtig angezeigt und zwar egal ob ich einen Taster drücke oder über die ETS einen Wert setze).

Wie komme ich den nun wieder zurück auf das originale 10_KNX Modul?

Gruß
Christian

Kann ich eigentlich irgendwo filtern, wer mir eine GA geschrieben hat? speziell will ich wo was anderes machen, wenn der Wert vom normalen aktor kommt, als wenn er vom watchdog kommt. Das ist dann bei mir nur eine "Notsteuerung".

Hi all,
Es gibt eine neue Version am github... - Details dazu im ersten Beitrag.

@Kohle77
versuch bitte nochmal diese version,  falls noch immer probleme, dann bitte jeweils ein list <device>
Hast du autocreate enabled? Ist das device (der "Taster") in FHEM definiert?....
Zur original version kommst du:
update delete https://raw.githubusercontent.com/erw111n/FHEM-KNX/main/controls_KNXevolution.txt
dann update und restart.

@JoeALLb:
geht mit last-sender reading! Ich verwende das, um festzustellen welcher Taster (in welchen Raum) das Alarm-GA aktiviert hat.....
das notify dazu:
PanikLicht:last-sender.* {
  my $wo = gadCheck($EVTPART1);
  my $mystate = ReadingsVal("$NAME",'state','undef');
  fhem "set AlarmHistory add $NAME $mystate - $wo";
}
die gadCheck-sub matched last-sender auf Raum-Bezeichnung....
l.g. erwin

Hallo Erwin,
ich habe das Problem gefunden. Das Problem war das der KNXD mit der Adresse 0.0.1 läuft aber auch der Aktor diese Adresse hatte.
Habe dem Aktor jetzt eine andere Adresse gegeben und ein dummy Gerät in der ETS angelegt das die Adresse der KNXD in der ETS blockiert.

Danke
Gruß
Christian

@Kohle77: Top Idee mit dem Dummy, sollte ich besser auch machen. Habe noch nie mit Dummy gearbeitet, welchen hast du genommen bzw. kannst du einen Empfehlen? Der Dummy würde bei mir auf der Hauptlinie liegen, wie KNXD auch 1.0.8

Hi,
ich bastle eigentlich nur FHEM. Das ETS Zeug macht mein Schwager.
Soweit ich weiß hat er ein neues Gebäudeteil angelegt und dann einfach ein Gerät dort eingesetzt und diesem einfach die Adresse gegeben.
Somit weiß die ETS das diese Adresse schon vergeben ist.

Gruß
Christian

Hallo,
irgendwie habe ich seit ich dieses neue Modul eingespielt habe probleme mit den Mappings. Kann mir da jemand in https://forum.fhem.de/index.php/topic,117869.0.html (https://forum.fhem.de/index.php/topic,117869.0.html) weiterhelfen?

Gruß
Christian

Wieso erhalte ich bei "set knxdevice on" die Meldung "KNX_Set_oldsyntax: ..."


Ist es wirklich so vorgesehen, dass es nur noch mit "set knxdevice g1 on" funktioniert?
Dankeschön.

ZitatWieso erhalte ich bei "set knxdevice on" ....

Das ist nur ein Hinweis, kein Fehler!
Dieser syntax wurde aus vor einigen Jahren durch den "neuen" syntax ergänzt und aus kompatibilitätsgründen beibehalten!
Er wird auch weiterhin funktionieren!  Es gibt aber, speziell bei den erweiterten dpts, Funktionen die im alten syntax einfach nicht vorgesehen waren. Daher die zweigleisigkeit!
Ich werde diese Log-Meldung in der nächsten version auf LogLevel 4 ändern. Damit kommt das im "normalen" Betrieb nicht mehr.

Danke für den Hinweis.
erwin

OK, super, danke.
Wenn man übrigens DOIFs im Perl Modus einsetzt und die dort vorhandene Funktion fhem_set("device on g3"); verwendet, funktioniert das nicht: Die Meldung erscheint im Log, es wird aber nichts geschalten.
Vielleicht könntest du dir das noch anschauen?
Vielen Dank.

re: DOIF's

sorry nachdem ich doif überhaupt nicht verwende, gibts 2 Möglichkeiten:

1) versuch mal mit doif "set device g3 on"
   falls es so funktioniert,dann ist das die Lösung....
  die neue syntax wurde vorallem für scripte, notify,... eingeführt.
2) FALLS NICHT:
   setze das KNX-device auf verbose 5 und beoachte den Eventmonitor was passiert, wenn das doif auslöst.
   das ist für mich dann die Unterscheidung das richtige Kommando vom doif kommt oder nicht!
   wenn das nicht hilft, dann bitte ein list device und einen Log-Auszug hier posten.
l.g. erwin

Hallo zusammen,

ich habe seit dem letzten Update Probleme mit dem Statustext meiner MDT-Glastaster. Ich habe lass mir auf den Glastastern zwei Zeilen Statustext anzeigen, die ich über ein entsprechendes Device bediene:

Internals:
   DEF        4/1/120:dpt16.000:Meldung:set:nosuffix
4/1/121:dpt16.000:Statustext1:set:nosuffix
4/1/122:dpt16.000:Statustext2:set:nosuffix
   DEVNAME    Visu.KiZ3.Info
   Eversion   E04.20 10-01-2021
   FIRSTGADNAME Meldung
   FUUID      5f5d111d-f33f-4189-41b8-ace088441a0ddee4
   GETSTRING 
   IODev      KNX
   NAME       Visu.KiZ3.Info
   NOTIFYDEV  global,TYPE=KNX
   NR         285
   NTFY_ORDER 50-Visu.KiZ3.Info
   SETSTRING  Statustext1:multiple,>CLR< Meldung:multiple,>CLR< Statustext2:multiple,>CLR<
   STATE      bbb <br/> 20.4 °C
   TYPE       KNX
   GADDETAILS:
     Meldung:
       CODE       04178
       GROUP      4/1/120
       MODEL      dpt16.000
       NO         1
       OPTION     set
       RDNAMEGET 
       RDNAMEPUT  Meldung
       RDNAMESET  Meldung
       SETLIST    :multiple,>CLR<
     Statustext1:
       CODE       04179
       GROUP      4/1/121
       MODEL      dpt16.000
       NO         2
       OPTION     set
       RDNAMEGET 
       RDNAMEPUT  Statustext1
       RDNAMESET  Statustext1
       SETLIST    :multiple,>CLR<
     Statustext2:
       CODE       0417a
       GROUP      4/1/122
       MODEL      dpt16.000
       NO         3
       OPTION     set
       RDNAMEGET 
       RDNAMEPUT  Statustext2
       RDNAMESET  Statustext2
       SETLIST    :multiple,>CLR<
   GADTABLE:
     04178      Meldung
     04179      Statustext1
     0417a      Statustext2
   Helper:
     DBLOG:
       Statustext1:
         dblog:
           TIME       1612552381.85846
           VALUE      bbb
       Statustext2:
         dblog:
           TIME       1612549390.03373
           VALUE      20.4
       last-sender:
         dblog:
           TIME       1612552381.85846
           VALUE      fhem
       state:
         dblog:
           TIME       1612552381.85846
           VALUE      bbb
   READINGS:
     2021-02-05 19:10:25   Meldung         
     2021-02-05 20:13:01   Statustext1     bbb
     2021-02-05 19:23:10   Statustext2     20.4 °C
     2021-02-05 20:13:01   last-sender     fhem
     2021-02-05 20:13:01   state           bbb
Attributes:
   IODev      KNX
   group      Visu
   room       EG_KiZ3
   stateFormat Statustext1 <br/> Statustext2
   verbose    5


Je Glastaster habe ich so zwei dpt16.000-Adressen, über die ich die beiden Zeilen befülle. Mit dem alten Modul funktioniert dies problemlos. Seit dem Update kommt irgendwie nichts mehr an. Zeitweise hatte ich den Eindruck, es funktioniert, aktuell ist es aber wieder so:
10_KNX.pm in der Version vom 10.12. --> alles geht
10_KNX.pm in der Version von 16.01. --> ich bekomme keinen Text auf die dpt16-Adressen der Glastaster geschrieben.

Verbose vom Device und vom KNX-Interface (knxd) habe ich auf 5 gesetzt, kann aber keine offensichtlichen Fehler finden:
Funktionieren 10_KNX:

2021.02.05 20:08:40.378 5: enter set Visu.KiZ3.Info: hash: HASH(0x5609cc2acba0), attributes: Visu.KiZ3.Info, Statustext1, aaaa
2021.02.05 20:08:40.378 5: set Visu.KiZ3.Info: desired target is gad Statustext1, command: aaaa, args:
2021.02.05 20:08:40.378 5: check value: aaaa, gadName: Statustext1
2021.02.05 20:08:40.378 5: check value: aaaa, gadName: Statustext1, model: dpt16.000, pattern: (?^ix:.{1,14})
2021.02.05 20:08:40.378 5: encode value: aaaa, gadName: Statustext1
2021.02.05 20:08:40.378 5: encode model: dpt16.000, code: dpt16, value: aaaa
2021.02.05 20:08:40.378 5: encode model: dpt16.000, code: dpt16, value: aaaa, numval: aaaa, hexval: 0061616161                   
2021.02.05 20:08:40.379 5: sending Cw041790061616161                   
2021.02.05 20:08:40.380 5: set Visu.KiZ3.Info: cmd: aaaa, value: aaaa, translated: 0061616161                   
2021.02.05 20:08:40.380 5: decode value: 0061616161                    , gadName: Statustext1
2021.02.05 20:08:40.380 5: decode model: dpt16.000, code: dpt16, value: 0061616161                   
2021.02.05 20:08:40.380 5: decode model: dpt16.000, code: dpt16, value: 0061616161, numval: 0, state: aaaa
2021.02.05 20:08:40.384 5: exit set


Nicht-funktionierende 10_KNX:

2021.02.05 20:11:34.196 5: KNX_Set -enter: Visu.KiZ3.Info, Statustext1, aaaa
2021.02.05 20:11:34.196 5: KNX_Set: set Visu.KiZ3.Info: desired target is gad: Statustext1, command: aaaa, args:
2021.02.05 20:11:34.196 5: KNX_checkAndClean -enter: value= aaaa, gadName= Statustext1
2021.02.05 20:11:34.196 5: KNX_checkAndClean -exit: value= aaaa, gadName= Statustext1, model= dpt16.000, pattern= (?^ix:.{1,14})
2021.02.05 20:11:34.197 5: KNX_encodeByDpt: Statustext1 model: dpt16.000, code: dpt16, value: aaaa
2021.02.05 20:11:34.197 5: KNX_encodeByDpt -exit: model: dpt16.000, code: dpt16, value: aaaa, numval: aaaa, hexval: 0061616161
2021.02.05 20:11:34.197 5: sending Cw041790061616161
2021.02.05 20:11:34.198 5: KNX_Set: Visu.KiZ3.Info, cmd= aaaa, value= aaaa, translated= aaaa
2021.02.05 20:11:34.203 5: KNX_Set: -exit


Hat jemand ein ähnliches Verhalten?

Gruß Thorsten

Hi Thorsten,

kann ich mir auf die schnelle nicht erklären, weil:
die Zeilen:

sending Cw041790061616161 (Log ok)
...und
sending Cw041790061616161 (Log Fehler)

aus deinen Logs schauen absolut ident aus. Diese Message kommt aber schon aus dem TUL Modul (TUL_write), nachden das KNX-Modul die daten zum senden übergeben hat!
Abgesehen von den Log Meldungen, die im neuen modul etwas anders aussehen, schaut auch der Rest der beiden Logs gleich aus.
Ich gehe jetzt nicht davon aus, dass du am TUL Modul etwas geändert hast.
l.g. erwin
PS: Ich werde morgen versuchen, das nachzustellen.... Danke, daß du gleich alle relevanten infos zusammengestellt hast!

Ich hab dasselbe Problem.
Mir ist aufgefallen: Im Busmonitor schaut ein dpt16-Telegram so aus:
ASCII:test23
Von ETS gesendet:   74 65 73 74 32 33 00 00 00 00 00 00 00 00
Von FHEM gesendet: 74 65 73 74 32 33
Es werden also statt 16 nur 6 Bytes übetragen und das kommt bei den Tastern wohl nicht so gut an...
ASCII: test2345678987 funktioniert hingegen auch, wenn ich es von FHEM aus verschicke.
lg David

Hi all,

ja das ist eine Erklärung, ist mir auch aufgefallen, wird in der nächsten version  gefixt,
allerdings erklärt es nicht, warum es mit der alten version geht ???

Um das nochmal zu verifizieren (ich selbst hab kein reales dpt16-device):
Darf ich Thorsten bitten, einen 14 Char langen string von fhem an das device zu schicken - und feeback zu geben?
lg erwin

Hallo Erwin

kann das von David beschriebene Verhalten nachvollziehen. Ein String mit 14 Zeichen wird angezeigt, ein kürzerer String nicht.

Gruß Thorsten

Ok, danke dann haben wir eine Lösung!
ich sollte mich nicht so unbedingt an die standard-dokumente halten:  ;D

ZitatTo transfer strings of characters, datapoint types 16.000 and 16.001 allow sending text of up to 14 characters.

das ist zwar richtig, mehr als 14 char gehen nicht, aber weniger als 14 ? Hab ich wohl falsch interpretiert....
Die neue Version kommt Anfang nächter Woche.
l.g. erwin

Zitat von: erwin am 04 Februar 2021, 08:34:06
Ich werde diese Log-Meldung in der nächsten version auf LogLevel 4 ändern. Damit kommt das im "normalen" Betrieb nicht mehr.

Wäre es eventuell sinnvoller, dass die Meldung nur bei beispielsweise "set device on" nicht mehr kommt, wenn man jedoch explizit "set device on g2" verwendet, man über "... alte Syntax ..." informiert wird?
Wenn bei "set device on" wirklich "set device on g1" ankommt, sollte das doch auch auf die neue Syntax "set device g1 on" geändert werden oder?

Noch ein Bug: Wenn etwas so definiert ist: 1/1/10:dpt1:switch
und ich mache ein "set device switch toggle" dann wird immer nur ausgeschalten und nicht wieder ein.

David,

Zitat"set device switch toggle" dann wird immer nur ausgeschalten und nicht wieder ein

.. das kommt daher, weil bisher der ist-status vom "get" - reading abgefragt wurde, und nicht vom "set"... (also g1-get,...). Ist mir nicht aufgefallen, weil ich fast alle ga's mit nosuffix codiert habe.
Ich hab kurz überlegt, ob ich auf das state reading gehen soll, aber das könnte ja auch falsch sein (stateregex, statecmd,...). Ich hab's jetzt auf das "set"-reading geändert, auch auf die Gefahr hin, dass das nicht der aktuelle status ist... sondern der zuletzt aus fhem ausgeführte cmd. (der status könnte sich ja durch ein event kommend vom knx-bus ändern...)
TOGGLE: das ist auch so ein cmd-Konstrukt aus der "alten Zeit". Für FHEMWEB braucht mans nicht, das geht mit devstateIcon bzw. cmdIcon eleganter, aber evtl für's scripten!
wg. Log-Meldung: klingt sinnvoll,  kommt jetzt immer (im Loglevel 3) wenn das letztes wort g[0-9] ist.
Danke für den Input!
l.g. erwin

Toggle auf das Set reading zu setzen sehe ich als nicht zielführend an
Ich arbeite noch mit get und Set und würde mich ärgern, wenn es sich an set orientiert. Warum? Weil get logischer ist, dafür gibt es das Rückmeldungs KO bzw die GA. Werden bei euch alle Geräte nur über eine GA geschaltet und sonst nicht? Kann ich mir nicht vorstellen. Als Alternative könnte man mittels eins Attr den User entscheiden lassen und als Standard get lassen. Ich denke es dürfte sonst gerade bei alten Definitionen zu Problemen, kommen, wenn User sich auf einmal fragen, warum ihr Toggle nicht mehr richtig funktioniert.

Zitat von: Amenophis86 am 07 Februar 2021, 12:35:14
Toggle auf das Set reading zu setzen sehe ich als nicht zielführend an

Geräte, die kein Rückmeldungs KO haben, würden Toggle dann gar nicht unterstützen. Edit: das hat doch gar nichts mit Rückmeldeadressen zu tun sondern nur mit der Schalt-Adresse und dazugehörigem getG1/setG1, oder?
Wenn Toggle nur auf set basiert, würde das Toggle falsch schalten, wenn das Gerät außerhalb von FHEM geschalten wird.

Am besten wäre wsl. wenn Toggle entweder get oder set nehmen würde, je nachdem welches neuer ist, oder?

Es muss in FHEM unterschieden werden zwischen Device, welche nur eine GA haben und über diese sowohl den Status als auch die Schaltung abbilden und Device, welche mehrere GA verbinden. Allerdings ist die Frage, ob bei Variante 1 dies dann dem KNX Status entspricht. Nehmen wir die Geräte von MDT zum Beispiel, die haben oft ein eigenes KO für die Rückmeldung, welches oft auf einer eigenen GA landet. In FHEM müsste es dann entweder ein Device für Status und eins für schalten geben, oder beide GA in einem Device zusammengefasst. Andere Geräte, wie zum Beispiel die Speerfunktion eines BJ 6131/31 haben nur ein KO zum setzen und freigeben und keine Rückmeldung. Hier wäre es dann nur ein Device in FHEM.

Jetzt die Frage, was wäre die beste Lösung. Ich denke das Problem ist, dass unabhängig von Rückmeldung oder Schalten es immer sein kann, dass über eine weitere GA der Status geändert wird. Dies bekommt ein reines GA-Device in FHEM dann nicht mit, somit würde bei einem toggle nichts passieren. Daher wäre meine Empfehlung weiterhin, dass man mittels eines attr selbst einstellen kann, auf welches Reading toggle achten soll (am beste sogar mit der set magic (https://wiki.fhem.de/wiki/Set_magic), damit es auch aus einem anderen Device den Status holen kann) und als default weiterhin get zu lassen.

Und wenn das toggle einfach beim generellen state nachschaut? Das würde doch bei Geräten mit nur einer, als auch bei Geräten mit Schalt- und Rückmeldeadresse funktionieren, oder?
Natürlich darf man dann das Reading mittels stateCmd nicht dahingehend verändern, dass toggle nicht mehr weiß in welchem Status sich das Gerät befindet. (darf nur on/off sein)
stateRegex aber wirkt sich ja nur auf die Anzeige aus, nicht aufs Reading, oder?

und was widerspricht in deinem Vorschlag zu state meinem attr Vorschlag, der bisher als einziger alle Möglichkeiten abdeckt? Bei deiner Variante nennst du ja selbst wieder ein Problem, wo es nicht passt.

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.

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

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:

Zitat von: erwin am 07 Februar 2021, 17:55:40
- 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!?

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.

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

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

Also wenn etwas so definiert ist:
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?

ZitatUnd 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:
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

Hört sich gut an mit get bzw set.

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

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

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

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

Zitat von: erwin am 10 Februar 2021, 15:27:49
Das ist Selbstbewusstsein!  >:(

Hast ihn ja gefunden und konntest über deinen Schatten springen ;) :D

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

Meine typische Definition:
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?

:-\

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 

Danke, eingespielt und funktioniert.

Das Löschen war kein Problem
deletereading KNX_.* .etG.

Ich hätte noch eine Anregung:
Wäre es eventuell möglich das Tul-Modul non-blocking zu machen?
Beim Verwenden von "apptime max" erscheint mir ganz oben immer die Funktion TUL_Read mit ca. 230 Millisekunden.

Das klingt jetzt zwar nicht nach viel, wenn aber, wie bei mir, Berechnungen auf Basis der Zeitdifferenz von zwei Pulsen meines Stromzählers laufen, können diese 0,2 sek. das Ergebnis bei hohen Strömen ganz schön beeinflussen...

Hi lichtimc,

ZitatWäre es eventuell möglich das Tul-Modul non-blocking zu machen?

.. im Prinzip ja, allerdings würde das für dein Problem nix bringen. -
das Blocking-Modul bringt nichts für die Laufzeit im Code, es verhindert nur dass der restliche FHEM-Prozess auf das Ergebniss wartet und sonst nix tut!
bei mir ist die apptime-max für KNX_TUL 185ms, average 40ms - also auch ziemlich viel.
ich hab kurz geschaut, was/wie apptime eigentlich misst:
Meiner Meinung nach wird gemessen in der fhem.pl:
- Start Zeitnehmung: fhem.pl ruft call TUL_read auf
    diese ruft etliche subs im TUL-Modul auf, dann mittels dispatch die KNX_parse funktion im KNX-Modul. Dort werden am Ende die Readings gesetzt.
   KNX_parse return - zurück in die TUL-Parse - zurück in TUL_read - return in fhem.pl
- Stop Zeitnehmung!
Langer Rede kurzer Sinn: dazwischen gibts keine Zwischenzeiten.
Wir wissen also nicht, wo in dem Prozess die Zeit verbraucht wird...gehe aber davon aus, dass das im KNX-Modul ist, weil dort die komplexeren dinge erledigt werden müssen.   

Messen von Zeitdifferenzen mit FHEM: würde ich so nicht machen. Begründung: FHEM und auch das Betriebssystem sind NICHT real-time Prozesse! Soll heissen, FHEM könnte jederzeit vom Betriebsystem unterbrochen werden, weil es was besseres zu tun hat.. Das spielt im Minutenbereich kaum eine Rolle, aber im (sub-)sekunden Bereich ist das relevant, wie du richtig schreibst
Ich bin zwar nicht sicher, ob ich das richtig verstehe,

ZitatBerechnungen auf Basis der Zeitdifferenz von zwei Pulsen meines Stromzählers

aber das würde ich anders lösen!

Rechenbeispiel:
Annahme: ein Zähler gibt 1000 Imp/KWh aus. Die aktuelle Leistung ist 10 kW.
ergibt: 2,77 Imp/sec oder 360  msec / Imp.
wenn jetzt jeder Impuls ein KNX-Paket am Bus auslöst, ein Packet ca. 20+Bytes hat+Arbritierung, nehme ich ca. 20ms BusZeit für ein Packet an.
20ms * 2,77 Imp/sec = 55,4 ms /sec Bus-belegt-  also 5,5% -kein Problem
Alle 360ms kommt ein Bus Telegram in FHEM an: bei einer processing-time von 180ms wären das 50% von der FHEM Leistung, und da fehlt noch der IO-overhead. - das ist ein Problem.

...ich würde das anders lösen: ein externer Zähler (z.B: ESP,Arduino mit einer timebase) der die Impulse / sekunde oder Minute zählt - und das ergebnis= ein Zähler an FHEM schickt. Damit bist du unabhängig von Latenz-zeiten im System!
l.g. erwin

Zitat von: erwin am 14 Februar 2021, 11:33:43
das Blocking-Modul bringt nichts für die Laufzeit im Code, es verhindert nur dass der restliche FHEM-Prozess auf das Ergebniss wartet und sonst nix tut!

Genau das ist ja relevant, oder? Wenn FHEM mit der Berechnung nicht erst warten muss, bis der TUL und das KNX-Modul fertig sind, stimmt die Berechnung eher, weil sie gleich beginnen kann, sobald der zweite Puls da ist.
Ich habe das Modul ElectricityCalculator im Einsatz, und das macht das nunmal so. Langfristig hab ich natürlich vor die ganze Sache auszulagern, oder vielleicht kriege ich eh mal einen digitalen Stromzähler, aber zurzeit ist es halt noch der Ferarri Zähler und ich greife die Umdrehungen des Zählerrads ab.

Ich hatte mit dem CUL-Modul das selbe Problem, nur hat das 3-4 Sekunden blockiert, wenn man den Stick manuell "deaktiviert" hatte, weil es solange versucht hatte wiederzuverbinden und nicht non-blocking war. Die Berechnungen des aktuellen Verbrauchs stimmten somit überhaupt nicht, aber nachdem Rudi das Verbinden des CUL-Sticks non-blocking gemacht hatte, stimmten die Berechnungen wieder viel besser.

Zitatweil sie gleich beginnen kann, sobald der zweite Puls da ist.

nein, auch der zweite Impuls braucht den Durchlauf durch TUL-KNX bevor die Daten verfügbar sind, genauso wie der erste!
Die Laufzeiten wären ja auch überhaupt nicht relevant, wenn sie immer exact gleich wären. Dein Messergebniss (Zeit zwischen 2 Impulsen) wird durch die unterschiedlichen Laufzeiten verfälscht, nicht durch die absoluten. Die absoluten laufzeiten bedeuten nur, dass jedes Ergebnis um die Laufzeit später verfügbar ist.
Wenn ich davon ausgehe, dass die KNX-Message beim 1. und 2. Impuls die gleiche ist, dann wir auch immmer der gleiche code durchlaufen, damit wäre auch die absolute Laufzeit immer dieselbe, außer: Irgendeinanderer code unterbricht! Höchstwahrscheinlich das Betriebssystem / ein anderer Task! (=Unterschied zw. apptime max und avg bzw. min)
N.B: Die nonblocking-Variante erhöht die (absolute) Laufzeit deutlich, da wird ein 2ter fhem process gestartet, und die delta Laufzeiten werden genauso passieren, weil systembedingt.

PS: beim ElectricityCalculator sind die daten schon da inkl. Timestamps, der macht nur Berechnungen, da macht non-blocking Sinn, damit fhem nicht damit aufgehalten wird.
PSS: beim CUL-Modul ist das Device-open non-blocking, die "empfangs-Funktion" ist vergleichbar mit der vom TUL-Modul.
l.g. erwin

Mal so als Tipp, ich habe für zeitkritische Module eine zweite FHEM Instanz auf dem gleichen PI laufen. Die Daten werden mittels RFHEM übertragen. Damit kannst du entweder alles zeitkritische abkoppeln oder du schiebst Module, welche blocking sind in die zweite Instanz.

Zitat von: Amenophis86 am 14 Februar 2021, 19:09:21
Mal so als Tipp, ich habe für zeitkritische Module eine zweite FHEM Instanz auf dem gleichen PI laufen. Die Daten werden mittels RFHEM übertragen. Damit kannst du entweder alles zeitkritische abkoppeln oder du schiebst Module, welche blocking sind in die zweite Instanz.

Genau das habe ich mir auch schon überlegt einzurichten, danke für den Tipp. Am liebsten wäre mir dennoch, wenn so viele Module wie möglich non-blocking wären, weil dann fhem immer gleich für den nächsten Befehl verfügbar ist. (oder ich verstehe das ganz falsch)

@erwin: non blocking: Verhindert die verzögerte Ausführung eines Befehls (zb. "Licht an" oder "empfange Puls und berechne aktuellen Verbrauch im Bezug auf vorherigen Puls"), wenn eine blockierende Funktion noch in Ausführung ist. Genau so hab ich es bei mir beobachtet. Die CUL Funktion ist lt. "apptime max" über 3 Sekunden lang gehangen und danach hat sich erst das Licht eingeschalten, obwohl der Befehl viel früher kam und ich hatte eine total falsche Berechnung des aktuellen Verbrauchs im ElectricityCalculator. Seitdem Rudi die eine Methode non-blocking gemacht hat, tritt dieses Phänomen nicht mehr auf und die Berechnungen passen einigermaßen. (Ich habe sonst keine so lange Blockade mehr, also funktionieren die ganzen Befehle wieder quasi instant, da fallen die 0,2sek nämlich nicht auf. Und seitdem rechnet eben auch das ElectricityCalculator-Modul wieder viel genauer.
Noch genauer muss es also meiner Ansicht nach rechnen, wenn eine weitere Funktion, die bei "apptime max" ganz oben angezeigt wird, non-blocking gemacht wird. Genau so sind ja meine Beobachtungen...

ahh,
jetzt erst versteh ich deinen Punkt:
falls zwischen 2 "Mess-Messages" irgendein anderer Event (KNX oder CUL oder beliebig) FHEM blockiert - dann ist dein Messergebnis verfälscht.
Ich war zusehr auf das timing im KNX-Modul fixiert.....
zweite FHEM Instanz wär ein Ansatz, externe Zeit-differenzmessung ein anderer. Da gibts auch fertige KNX-Module,die das können (Puls-Counter), oder "Bastel-Lösungen", zb. Tasmota o.ä.
PS: ich hab jetzt apptime 2 Tage am laufen:

name                                     function                          max     count      total      average   maxDly   avgDly
  myTUL                                  TUL_Read                            180     17843    73156.31     4.10     0.00     0.00

..die average find ich in Anbetracht der komplexen Auswertung ok. Jetzt wär noch interessant zu wissen, wie die Streuung der Werte ist....
sorry erwin

Ja ist sicher ok und für das Einschalten von Lampen und ähnliches auch überhaupt kein Problem.

Nachdem bei apptime der Tul bei mir ganz oben ist, und meine Ansicht bis jetzt war "desto mehr non-blocking desto besser", dachte ich, ich frag mal, ob es möglich ist, das non-blocking zu machen.

Wenn es aus diversen anderen Gründen (die ich nicht kenne  :P ) keinen Sinn macht, dann ist das auch gut natürlich. :)

Danke jedenfalls für die Antworten!

lichtmic hat schon recht, wenn möglich sollte ein Modul immer auf non-blocking setzen, insbesondere dann, wenn es komplex ist. Wie groß der Aufwand ist und, on du es umsetzen willst, kannst nur du entscheiden erwin.

Hi,

danke für die diskussion, die Geschichte hatte ich bisher nicht auf dem Radar!
Es wird allerdings noch etwas dauern, bis ich das angehe. Dzt. versuche ich den bestehenden code so zu optimieren, dass er für mich wartbar und verständlich ist. und ein "feature-request" ist auch noch offen.
Das wird noch ein oder 2 Iterationen brauchen, mal sehen.
Was mich dzt. zu dem Thema verwirrt, ist die Diskrepanz zwischen max=180ms und avg=4.1ms - da reden wir von einem Faktor 40 für dasselbe Stück code!!!
Mag schon sein, das z.b. ein oder 2 mehr Log messages geschrieben werden oder code "foreach../if.." abhängig von dpt,options,Anzahl GAD's pro definition...., das könnte einen Faktor 5 erklären, aber 40???
Falls ihr Tips habt, wie/warum/wo die Zeiten so unterschiedlich sein können, bzw. Tools mit denen man das  entdecken kann, wär ich sehr dankbar!
lg. erwin

Kann mir jemand sagen, wie ich autocreate dazu bekomme diese Codes abzufangen:

2021.02.18 18:59:59 3: KNX: Unknown code C01002r0110e00, help me!
2021.02.18 18:59:59 3: KNX: Unknown code C01124p0110e079e, help me!
2021.02.18 18:59:59 3: KNX: Unknown code C01002r0110f00, help me!
2021.02.18 18:59:59 3: KNX: Unknown code C01125p0110f0c33, help me!
2021.02.18 18:59:59 3: KNX: Unknown code C01002r0111000, help me!
2021.02.18 18:59:59 3: KNX: Unknown code C01125p011100c01, help me!
2021.02.18 19:00:00 3: KNX: Unknown code C01002r0111100, help me!
2021.02.18 19:00:00 3: KNX: Unknown code C01125p011110c01, help me!
2021.02.18 19:00:00 3: KNX: Unknown code C01002r0111200, help me!
2021.02.18 19:00:00 3: KNX: Unknown code C01125p01112076c, help me!

Die müssten von KNX kommen und mir ist nicht klar wieso autocreate hier kein Device anlegt. Ich habe auch schon autocreate gelöscht und neu definiert und FHEM mal komplett neu gestartet. Aber nix hat geholfen.

Hi Amenophis86,
Die Messages kommen vom Bus, nicht von FHEM, nehme ich an,oder?
irgendein Gerät macht ein read auf die GA 1/1/14 und dieses Gerät antwortet auch darauf.
Beim autocreate gibts einen default, wieviele Messages/Zeitraum kommen müssen, bevor ein device angelegt wird siehe: attr: autocreateThreshold
ich glaube default ist 60 sekunden, die Anzahl weiß ich jetzt nicht....

Ich hab in einer der letzten Versionen Modul-spezifische defaults eingeführt: 2Messages in 10 sekunden, das ist jedenfalls weniger als der default.
das findest du in der 10_KNX.pm unter $hash->{autocreate}.

die "unknow codes..." messages ganz zu vermeiden geht evtl. im TUL- bzw. KNXTUL-Modul, ganz durchschau ich die Konsequenzen allerdings noch nicht..
l.g. erwin

Woran hast du erkannt, dass es 1/1/14 ist? Damit ich beim nächsten Mal einfach das Device selbst anlegen kann.

Wenn ich dich richtig verstehe, dann müsste das Gerät 2x in 10 Sekunden eine Antwort gesendet haben um automatisch angelegt zu werden? Das wäre doch dann aber kontraproduktiv, oder? Würde es nicht mehr Sinn machen die Zeit hoch zu setzen, damit die Device sicher angelegt werden?

ZitatWoran hast du erkannt, dass es 1/1/14 ist

Unknown code C01002r0110e00, help me!
C<src-addresse><r> 01 1 0e <value>

der system-weite autocreate threshold ist 3* in 60 sekunden , dass gilt für alle devices. Was richtig oder falsch ist, bin ich mir nicht sicher. Z.b. Ein ThemperaturSensor, der alle 3 Minuten sendet, würde auch mit dem default nicht angelegt werden, aber jedesmal eine "unknown..." message produzieren.
l.g. erwin

Zitat von: erwin am 19 Februar 2021, 11:55:01

Code Auswählen Erweitern

Unknown code C01002r0110e00, help me!
C<src-addresse><r> 01 1 0e <value>

Ah das ist der Hexcode für die GA Adresse, vielen Dank

Zitat
der system-weite autocreate threshold ist 3* in 60 sekunden , dass gilt für alle devices. Was richtig oder falsch ist, bin ich mir nicht sicher. Z.b. Ein ThemperaturSensor, der alle 3 Minuten sendet, würde auch mit dem default nicht angelegt werden, aber jedesmal eine "unknown..." message produzieren.

Ich verstehe. Dann muss das vermutlich wirklich jeder für sich entscheiden, ob er will, dass jedes Gerät angelegt wird (1x Nachricht in 10 Sekunden zum Beispiel) oder nur bestimmte Geräte und dann die Werte entsprechend anpassen.
Kann es sein, dass das help me auch kommt, wenn es das Device schon gibt aber auf disable 1 steht? Und ist es neu, dass neue Geräte auf disable 1 gestellt werden? Ich glaube nämlich, dass das früher nicht war mit disable und deswegen weniger help me Nachrichten gekommen sind, wenn es das Device schon gab.

ZitatKann es sein, dass das help me auch kommt

das muss ich mir anschauen...

ZitatUnd ist es neu, dass neue Geräte auf disable 1 gestellt werden?

Ja, das ist neu. Grund ist, das der User sowieso die def ändern muss (zumindest model)  sonst kann das device die ankommenden Nachrichten ja nicht richtig interpretieren. Und mit disable schmeisst die parse funktion gleich die ankommende message weg (=schneller).
Das mit den unknown messages, wenn das device schon exisitert, aber disabled ist, schau ich mir noch an.
PS: die "unknown code xxx, pls. help me" werden aus der fhem.pl geschickt, ausgelöst werden sie durch die 00_TUL, bzw. 00_KNXTUL Module...

Hallo zusammen, habe heute das Update eingespielt und gleich angefangen mit DPT16.001 spielen. Gerade im Log folgendes gesehen:
2021.02.24 11:42:03 1: PERL WARNING: Illegal hexadecimal digit ' ' ignored at ./FHEM/10_KNX.pm line 2082.

Hi EinEinFach,

Line 2082 ist bei dieser version mitten in der cmd-ref, dort kann/darf nichts exektuiert werden, kannst du bitte nochmal checken?
und: geht irgendwas nicht? Was versuchst du - was ist das ergebnis - ich brauch was zum nachstellen.
l.g. erwin

Ich schicke einige Statis an den Glastaster 2 von MDT. Der String war "Gesperrt", wo das einmalig im Log aufgetaucht ist. Wie gesagt, das war nur einmalig da, sonst tut alles wie es soll. Ich beobachte das, sollte was neues auftauchen, versuche ich mehr Input zu liefern

Gruß

@EinEinfach: ok,schaun wir mal...

@All:
ich bin dabei, die nächste Version zu releasen:
u.a. wird dort ein neues Attribut eingeführt, siehe diskussion in diesem Thread zum Thema toggle-cmd.
Die neue cmd-ref:
toggleSRC - lookup current value before issuing "set device <gadName> toggle" cmd.
FHEM has to retrieve a current value to make the toggle-cmd acting correctly. This attribute can be used to define the source of the current value.
Format is: <devicename>:<readingname>. If you want to use a reading from own device, you can use "$self" as devicename. Be aware that only on and off are supported as valid values when defining device:readingname.
If this attribute is not defined, the current value will be taken from owndevice:readingName-get or, if readingName-get is not defined, the value will be taken from readingName-set.
...sollte soweit rückwärtskompatibel sein und nun auch "spezial-fälle" abdecken.
Die Frage: der name toggleSRC gefällt mir überhaupt nicht, mir ist nur nix besseres eingefallen....
Hab ihr bessere Vorschläge für den Attribut-Namen? - noch kann ich ganz leicht ändern...
l.g. erwin

Top, für die Einführung.

Ich schlage einfach nur KNX_toggle vor. Zum einen bin ich ein Fan davon, wenn attr die nur für ein Modul sind entsprechend mit dem Modulnamen beginnen und zum zweiten bedarf es aus meiner Sicht das Kürzel SRC nicht.

Hi,
"KNX_toggle" klingt logisch und plausibel...und gefällt mir wesentlich besser!
Ich lass die Version noch ein paar Tage auf meine Prod-system laufen...
Falls in den nächsten Tagen kein "genialer name" ;D kommt, wirds KNX_toogle!
Danke erwin 

Hi All,
eine neue Version E04.43 ist am Git:
change History:
1) fix: en-de-code dpt 6,8,13
2) fix autocreate- unknown code..
ich hab autocreateThreshold wieder aus dem Modul entfernt, nachdem das als Attribute im autocreate modul vom user selbst definiert
werden kann, und zwar auch KNX spezifisch! Z.b: "attr autocreate autocreateThreshold KNX_.*:2:10"
-übersetzt: definiere ein KNX_xxyyzzz device falls binnen 10 sekunden 2 Messages mit der gleichen GA-addr. vom Bus ankommen.
unknown codes sollten jetzt keine mehr vorkommen!
Die devices sind default disabled, es muss ein richtiger dpt-typ manuell definiert werden.
3) Set-readings / get-readings
Ich habe versucht zu trennen: die Funktion der set/get/listenonly option (verhindern von set- od. get-cmd) von der Logik wann set- / get-readings gesetzt werden.
set-readings werden NUR MEHR gesetzt, sobald ein FHEM set-cmd ausgeführt wird.
  bisher: wurde das set reading auch gesetzt, fall die "set-option" definiert war und eine Msg vom Bus kam..
  (es gab kein get-reading wenn die "set-option" definiert war)
get-readings werden für ALLE messages gesetzt, die vom Bus kommen (unabhängig von set-option).
- das kann bei unterschiedlichen Implementationen durchaus zu Unterschieden führen: (das ist zwar nicht neu, aber kann fürs debuggen nützlich sein!)
- Folgende Varianten hab ich bisher festellen können:
- a) ein FHEM-set cmd erzeugt KEIN get-reading. Das wäre der "Normalfall"
- b) ein FHEM-set cmd erzeugt EIN get-reading, zusätzlich zum set-reading.
Mögliche Ursachen:
b1) der IP- Layer echoed die gesendete FHEM-set msg. (Trifft für KNXTUL multicast zu)
b2) in der ETS (bzw. im KNX-device) ist für diese GA das Flag update/aktualisieren gesetzt.
b3) sehr alte KNXD-Versionen machen das auch auf Tunnel-connections.
Was zutrifft kann man evtl. erkennen, wenn man im event-monitor auf last-sender schaut...
- Mehrfache get-readings (für dieselbe GA) kommen vor:
a) Falls am KNX-TP1 ein resend passiert.
b) TASMOTA-KNX - schickt jede msg 3mal, falls in den KNX-definitionen im Tasmota "Communication Enhancement" eingestellt ist.
c) wenn es in einem LAN mehrere KNXD's mit "S" option bzw. KNX Router gibt, dann entstehen möglicherweise loops..
d) Falls gleichzeitig ein TUL UND ein KNXTUL Modul definiert ist! Verhalten ist nicht deterministisch, manchmal kommen die msgs über beide Interfaces, manchmal nur über eins von beiden...
Lt. KNX-specs darf es KEINE 2 Pfade zwischen 2 Geräten geben! (so hab ich es zumindest verstanden)
Falls jetzt jemand verwirrt ist, hab ich Verständnis dafür... Falls ihr die unterscheidung set-/get-reading nicht für weitere Logik braucht, empfehle ich die Verwendung der "noSuffix-option".
4) cmd-ref: umstellung von "<a name=" nach "<a id=" siehe:https://forum.fhem.de/index.php/topic,118915.msg1135123.html#msg1135123
5) Neu: Attribute KNX_toggle
ist in der cmdref im Detail beschrieben.

Das sollte für die nächste Zeit die letzte "gröbere" Änderung am Modul sein, fixes und neue Features natürlich ausgenommen.
Feedback willkommen! Bei Problemen bitte mit einem "list <device>" und evtl. Log-Auszug, falls sinnvoll.
l.g.erwin

Läuft bei mir bisher unauffällig stabil, auch die 00_KNXTUL.pm.

Läuft bei mir auch unauffällig und stabil.

dito

Das sind ja good news, und ich dachte schon das verwendet keiner...  ;D
Wär schon interessant, wieviele user/installationen das nutzen?
Frage an die Experten: gibts am GIT eine Möglichkeit das zu finden? Abgesehen von views/pulls... Die downloads wären interessant!
l.g. erwin

Bei offiziellen Modulen gibt es das in FHEM aber bei git weiß ich es nicht. Bzw vll geht das auch bei nicht offiziellen Modulen. https://fhem.de/stats/statistics.html

Hallo Zusammen,

vielen Dank für die Weiterentwicklung des Modules.

Leider ist bei mir durch das Update ein Problem aufgetreten und ich  konnte ich in dem Thread nichts passendes dazu finden.
Scheinbar hat das Update einige meiner KNX Devices deaktviert ohne das ich diese wieder aktiveren kann.
Es ist kein disable Attribute vorhanden und auch ein setreading KNX_Heizung disable 0 brachte keinen Erfolg.

Update, shutdown restart etc. hab ich auch schon erfolglos probiert.

Anbei eine List definition.

Ausgelöst wurde das disable durch "9/0/47:dpt1.011:Warmwasser"
In der ETS kommt im Gruppenmonitor bei einem Get eine Rückmeldung mit DPT 1.011, Aktiv/Inaktiv.

Vielen Dank im Voraus!

Internals:
   DEF        9/0/46:dpt1.011:Heizen 9/0/47:dpt1.011:Warmwasser 9/0/41:dpt9.001:TemperaturOutside 9/0/42:dpt13.013:Heizen-Stromverbrauch 9/0/43:dpt13.013:Warmwasser-Stromverbrauch 9/0/44:dpt13.013:Umweltertrag
   DEVNAME    KNX_Heizung
   FIRSTGADNAME Heizen
   FUUID      5ddfecf9-f33f-28ca-1268-af970f7fdf65597b
   FVERSIONE  04.43 25-02-2021
   GETSTRING  Warmwasser:noArg Heizen-Stromverbrauch:noArg Umweltertrag:noArg TemperaturOutside:noArg Warmwasser-Stromverbrauch:noArg Heizen:noArg
   IODev      KNXD01
   KNXD01_MSGCNT 4
   KNXD01_RAWMSG C0100bw09029071b
   KNXD01_TIME 2021-04-11 15:09:17
   LASTInputDev KNXD01
   MSGCNT     4
   NAME       KNX_Heizung
   NOTIFYDEV  global,TYPE=KNX
   NR         143
   NTFY_ORDER 50-KNX_Heizung
   SETSTRING  Warmwasser:inactive,active Heizen-Stromverbrauch:slider,-2147483648,42949672,2147483647 Umweltertrag:slider,-2147483648,42949672,2147483647 TemperaturOutside:slider,-274,6710,670760 Warmwasser-Stromverbrauch:slider,-2147483648,42949672,2147483647 Heizen:inactive,active
   STATE      Temperatur Außen: 0.81 &deg;C<br /><br />Heizen FBH: inactive<br />Heizen WW: inactive<br /><br />Stromverbrauch FBH:4771 kWh<br />Stromverbrauch WW: 3202 kWh
   TYPE       KNX
   GADDETAILS:
     Heizen:
       CODE       0902e
       GROUP      9/0/46
       MODEL      dpt1.011
       NO         1
       OPTION     
       RDNAMEGET  Heizen-get
       RDNAMEPUT  Heizen-put
       RDNAMESET  Heizen-set
       SETLIST    :inactive,active
     Heizen-Stromverbrauch:
       CODE       0902a
       GROUP      9/0/42
       MODEL      dpt13.013
       NO         4
       OPTION     
       RDNAMEGET  Heizen-Stromverbrauch-get
       RDNAMEPUT  Heizen-Stromverbrauch-put
       RDNAMESET  Heizen-Stromverbrauch-set
       SETLIST    :slider,-2147483648,42949672,2147483647
     TemperaturOutside:
       CODE       09029
       GROUP      9/0/41
       MODEL      dpt9.001
       NO         3
       OPTION     
       RDNAMEGET  TemperaturOutside-get
       RDNAMEPUT  TemperaturOutside-put
       RDNAMESET  TemperaturOutside-set
       SETLIST    :slider,-274,6710,670760
     Umweltertrag:
       CODE       0902c
       GROUP      9/0/44
       MODEL      dpt13.013
       NO         6
       OPTION     
       RDNAMEGET  Umweltertrag-get
       RDNAMEPUT  Umweltertrag-put
       RDNAMESET  Umweltertrag-set
       SETLIST    :slider,-2147483648,42949672,2147483647
     Warmwasser:
       CODE       0902f
       GROUP      9/0/47
       MODEL      dpt1.011
       NO         2
       OPTION     
       RDNAMEGET  Warmwasser-get
       RDNAMEPUT  Warmwasser-put
       RDNAMESET  Warmwasser-set
       SETLIST    :inactive,active
     Warmwasser-Stromverbrauch:
       CODE       0902b
       GROUP      9/0/43
       MODEL      dpt13.013
       NO         5
       OPTION     
       RDNAMEGET  Warmwasser-Stromverbrauch-get
       RDNAMEPUT  Warmwasser-Stromverbrauch-put
       RDNAMESET  Warmwasser-Stromverbrauch-set
       SETLIST    :slider,-2147483648,42949672,2147483647
   GADTABLE:
     09029      TemperaturOutside
     0902a      Heizen-Stromverbrauch
     0902b      Warmwasser-Stromverbrauch
     0902c      Umweltertrag
     0902e      Heizen
     0902f      Warmwasser
   READINGS:
     2021-04-11 14:43:29   FBH-Heizphase   0
     2021-04-11 14:43:29   Heizen-Stromverbrauch 4771
     2021-04-11 14:43:29   Heizen-Stromverbrauch-get 4771 kWh
     2021-04-11 14:43:29   Heizen-get      inactive
     2021-04-11 14:43:29   TemperaturOutside-Value 0.81
     2021-04-11 14:43:29   TemperaturOutside-get 0.81 &deg;C
     2021-04-11 14:43:29   Umweltertrag    14298
     2021-04-11 14:43:29   Umweltertrag-get 14298 kWh
     2021-04-11 14:43:29   Warmwasser-Heizphase 0
     2021-04-11 14:43:29   Warmwasser-Stromverbrauch 3202
     2021-04-11 14:43:29   Warmwasser-Stromverbrauch-get 3202 kWh
     2021-04-11 14:43:29   Warmwasser-get  inactive
     2021-04-11 14:43:29   last-sender     1.0.11
     2021-04-11 14:43:29   state           inactive
Attributes:
   DbLogInclude Heizen-get,TemperaturOutside-Value,Warmwasser-get
   IODev      KNXD01
   room       30_KNX
   stateFormat {"Temperatur Außen: " . ReadingsVal($name,"TemperaturOutside-get",0) .
"<br /><br />Heizen FBH: " . ReadingsVal($name,"Heizen-get",0) .
"<br />Heizen WW: " . ReadingsVal($name,"Warmwasser-get",0) .
"<br /><br />Stromverbrauch FBH:" . ReadingsVal($name,"Heizen-Stromverbrauch-get",0).
"<br />Stromverbrauch WW: " . ReadingsVal($name,"Warmwasser-Stromverbrauch-get",0)}
   userReadings TemperaturOutside-Value { ReadingsNum($name,"TemperaturOutside-get",0) }, FBH-Heizphase { if(ReadingsVal($name,'Heizen-get',0) eq "active") {"1"} else {"0"}}, Warmwasser-Heizphase { if(ReadingsVal($name,'Warmwasser-get',0) eq "active") {"1"} else {"0"}}, Heizen-Stromverbrauch {ReadingsNum($name,"Heizen-Stromverbrauch-get",0)}, Warmwasser-Stromverbrauch {ReadingsNum($name,"Warmwasser-Stromverbrauch-get",0)}, Umweltertrag {ReadingsNum($name,"Umweltertrag-get",0)}

Hi xps!

Ich hab dein device bei mir nachgebaut und gegen den ETS-Monitor getestet, ich kann in deinem list keinen Fehler erkennen! Gibts im Log Fehlermeldungen?
Das mit dem disable versteh ich nicht, das ist ein Attribut, dass es in (fast) allen devices gibt, falls das bei dir nicht verfügbar ist, dann hast du ein grundsätzliches Problem!

Einige Anmerkungen hab ich schon, deine Definition erscheint mir zu kompliziert:
Wenn du die Einheiten in den readings nicht haben willst (diese Annahme entnehme ich deinen Userreadings) dann definiere doch: 9/0/41:dpt9:TemperaturOutside:listenonly:nosuffix statt 9/0/41:dpt9.001:TemperaturOutside
und 9/0/46:dpt1.000:Heizen statt 9/0/46:dpt1.011:Heizen und 9/0/47:dpt1.000:Warmwasser statt 9/0/47:dpt1.011:Warmwasser, usw.

Auf diese Weise kannst du ALLE userreadings eliminieren! Und auch das stateFormat vereinfachen (und falls gewünscht die Einheiten dort hinzufügen).
schau dir bitte auch noch die cmd-ref zu den optionen set/get/listenonly/nosuffix an, evtl. ist da auch was brauchbares für dich dabei.
l.g. erwin

Hallo Erwin,

danke für deine Antwort.
Ich habe extra eine "frische" Instanz auf einem zweiten Server aufgebaut um zu sehen ob es etwas mit meiner Instanz zu tun hat.
Auch auf dieser habe ich das Problem sobald ich das erste mal für Warmwasser ein "get" anfrage.

Das Device lässt sich dann auch nicht mehr enablen.

Generell sehe ich das disable attribut schon und verwende es auch vereinzelt - jedoch ist es bei dem automatisch deaktivierten Device nicht sichtbar.  :-\

Mein Log zeigt folgendes im Verbose 5:
2021.04.12 09:24:15 5 : sending Cr0902f
2021.04.12 09:24:15 5 : SimpleRead msg.type: reply, msg.src: 0100b, msg.dst: 0902f
2021.04.12 09:24:15 5 : SimpleRead data: 00
2021.04.12 09:24:15 4 : KNXD01: C0100bp0902f00
2021.04.12 09:24:15 5 : KNXD01: dispatch C0100bp0902f00
2021.04.12 09:24:15 5 : KNX_Parse -enter: IO-name: KNXD01, dest: 0902f, msg: C0100bp0902f00
2021.04.12 09:24:15 5 : KNX_parse -exit
2021-04-12 09:24:15 KNX KNX_Heizung5 Warmwasser-get: inactive
2021-04-12 09:24:15 KNX KNX_Heizung5 last-sender: 1.0.11
2021-04-12 09:24:15 KNX KNX_Heizung5 inactive

Internals:
   CFGFN     
   DEF        9/0/47:dpt1.011:Warmwasser
   DEVNAME    KNX_Heizung5
   FIRSTGADNAME Warmwasser
   FUUID      6073f59a-f33f-ac85-5b7c-97fcdab4a818b842
   FVERSIONE  04.43 25-02-2021
   GETSTRING  Warmwasser:noArg
   IODev      KNXD01
   KNXD01_MSGCNT 1
   KNXD01_RAWMSG C0100bp0902f00
   KNXD01_TIME 2021-04-12 09:24:15
   LASTInputDev KNXD01
   MSGCNT     1
   NAME       KNX_Heizung5
   NOTIFYDEV  global,TYPE=KNX
   NR         429
   NTFY_ORDER 50-KNX_Heizung5
   SETSTRING  Warmwasser:inactive,active
   STATE      inactive
   TYPE       KNX
   GADDETAILS:
     Warmwasser:
       CODE       0902f
       GROUP      9/0/47
       MODEL      dpt1.011
       NO         1
       OPTION     
       RDNAMEGET  Warmwasser-get
       RDNAMEPUT  Warmwasser-put
       RDNAMESET  Warmwasser-set
       SETLIST    :inactive,active
   GADTABLE:
     0902f      Warmwasser
   READINGS:
     2021-04-12 09:24:15   Warmwasser-get  inactive
     2021-04-12 09:24:15   last-sender     1.0.11
     2021-04-12 09:24:15   state           inactive
Attributes:
   IODev      KNXD01
   room       30_KNX

Hi xps,

ok: du machst ein get auf Warmwasser - und zurück kommt "inactive" (von einem sender 1.0.11)
Das ist alles ok! das device wird nicht deaktiviert! das ist ein wert wie jeder andere - siehe cmd-ref- dpt1.011
versuch bitte mal das device auf dpt1.000 zu ändern, dann kommt sicher 0 zurück. (bzw 1 wenn WW an ist)

Hi Erwin,

vermutlich hab ich mich falsch ausgedrückt.
Zuerst kommt das inactive - danach kommt dein "KNX_Get device: KNX_Heizung5 is disabled" in einem Popup.
Die Meldung bekomme ich erst wieder weg sobald ich das Device lösche und neu anlege - dann habe ich genau wieder das gleiche Problem.

Dein Tipp mit dpt1.000 hat geklappt, sobald ich das Device auf dpt1.000 abändere taucht das Problem übrigens nicht mehr auf.
Jedoch ist lt. ETS die Rückgabe dpt1.011 und hat auch im alten KNX Modul bisher funktioniert.

LG xps

xps, du verstehst das falsch. "inactive" ist der Wert, welcher von deinem Aktor gesendet wird. dpt1.011 sendet active oder inactive als WERT zurück. Das ist nur eine andere Bezeichnung für on off / 1 0 oder was auch immer. Die DPT1 heißt, dass es zwei Werte gibt. Im Standard 0 und 1. Mittels der Zahlen nach dem Punkt änderst du die Werte für 0 und 1 in Strings um. Bei dpt1.011 also in inactive und active. Damit funktioniert es genau so, wie es soll. Wenn die Pumpe an ist, müsste als ein active als Rückmeldung kommen. Haste das mal versucht?

Edit:
Oder nimm mal eine Lampe und ändere dort auf dpt1.011 und schau mal was passiert. Dann bekommst du genau das gleiche, wie bei der Pumpe raus. active für Lampe an und inactive für Lampe aus.

Das Inactive der Rückgabewert ist, ist mir absolut klar.
Ich bekomme jedoch von FHEM die Rückmeldung dass das Device disabled ist nachdem ein response angekommen ist (sobald dpt1.011 hinterlegt ist).

Screenshot anbei.

LG xps

Zitat von: xps am 11 April 2021, 15:16:01
auch ein setreading KNX_Heizung disable 0 brachte keinen Erfolg.

mach mal attr <device> disable 0 und nicht mit setreading ändern. Disable ist ein attr und kein reading.

Hab ich schon zuvor probiert - das attribut ist gar nicht gesetzt.


Internals:
   CFGFN     
   DEF        9/0/47:dpt1.011:Warmwasser
   DEVNAME    KNX_Heizung5
   FIRSTGADNAME Warmwasser
   FUUID      60740ec6-f33f-ac85-7fe6-c07ec3e7848327ca
   FVERSIONE  04.43 25-02-2021
   GETSTRING  Warmwasser:noArg
   IODev      KNXD01
   KNXD01_MSGCNT 5
   KNXD01_RAWMSG C0100bp0902f00
   KNXD01_TIME 2021-04-12 11:25:05
   LASTInputDev KNXD01
   MSGCNT     5
   NAME       KNX_Heizung5
   NOTIFYDEV  global,TYPE=KNX
   NR         448
   NTFY_ORDER 50-KNX_Heizung5
   SETSTRING  Warmwasser:inactive,active
   STATE      inactive
   TYPE       KNX
   GADDETAILS:
     Warmwasser:
       CODE       0902f
       GROUP      9/0/47
       MODEL      dpt1.011
       NO         1
       OPTION     
       RDNAMEGET  Warmwasser-get
       RDNAMEPUT  Warmwasser-put
       RDNAMESET  Warmwasser-set
       SETLIST    :inactive,active
   GADTABLE:
     0902f      Warmwasser
   READINGS:
     2021-04-12 11:25:05   Warmwasser-get  inactive
     2021-04-12 11:25:05   last-sender     1.0.11
     2021-04-12 11:25:05   state           inactive
Attributes:
   IODev      KNXD01
   room       30_KNX



Internals:
   CFGFN     
   DEF        9/0/47:dpt1.011:Warmwasser
   DEVNAME    KNX_Heizung5
   FIRSTGADNAME Warmwasser
   FUUID      60740ec6-f33f-ac85-7fe6-c07ec3e7848327ca
   FVERSIONE  04.43 25-02-2021
   GETSTRING  Warmwasser:noArg
   IODev      KNXD01
   KNXD01_MSGCNT 5
   KNXD01_RAWMSG C0100bp0902f00
   KNXD01_TIME 2021-04-12 11:25:05
   LASTInputDev KNXD01
   MSGCNT     5
   NAME       KNX_Heizung5
   NOTIFYDEV  global,TYPE=KNX
   NR         448
   NTFY_ORDER 50-KNX_Heizung5
   SETSTRING  Warmwasser:inactive,active
   STATE      inactive
   TYPE       KNX
   GADDETAILS:
     Warmwasser:
       CODE       0902f
       GROUP      9/0/47
       MODEL      dpt1.011
       NO         1
       OPTION     
       RDNAMEGET  Warmwasser-get
       RDNAMEPUT  Warmwasser-put
       RDNAMESET  Warmwasser-set
       SETLIST    :inactive,active
   GADTABLE:
     0902f      Warmwasser
   READINGS:
     2021-04-12 11:25:05   Warmwasser-get  inactive
     2021-04-12 11:25:05   last-sender     1.0.11
     2021-04-12 11:25:05   state           inactive
Attributes:
   IODev      KNXD01
   disable    0
   room       30_KNX


Die Meldung dass das Device disabled sei kommt nach wie vor.

LG xps

Edit: Dabei macht es auch keinen Unterschied ob die Produktions-Instanz oder eine ganz frische FHEM Instanz auf einem anderen Server.

Hi
ok, jetzt hab ichs!

das Problem ist: ich hab in der get routine eine abfrage eingebaut: return "KNX_Get device: $name is disabled" if (IsDisabled($name));
wobei IsDisabled eine standard funktion in fhem ist.
Die reagiert aber in deinem Fall auf state = inactive (was durch deine definition dpt1.011) gesetzt wird.
ich muss mir was überlegen für die nächste version.....

Abhilfe: definiert dpt1.000 für die beiden Werte.
Die subcodes xxx aus dpt1.xxx  sind völlig gleichgültig wie das in der ETS definiert ist, die definieren nur wie das reading in fhem ausschaut! (Skalierung und Units) t

Danke, wieder ein Problem gefunden!
l.g. erwin 

Hi,
nichts zu danken, danke für deinen superschnellen Support!

Liebe Grüße
xps

Hi All,
Das nächste Update: 20210419 Version E04.52
Ich hab zwar beim letzten update versprochen, dass keine gröberen updates in nächster Zeit kommen werden,
aber der Lockdown...
- im Detail:
    - change: own package: FHEM::KNX
      replaced ok-dialog on get-cmd by "err-msg"
      replace eval by AnalyzePerlCommand
      docu correction
      fixed KNX_replaceByRegex
      fix IsDisabled when state = inactive
      modified dpt patterns algo
      fix DbLog_split
    - new: added FingerPrintFn

Es sollte keine Änderungen in Usage, Definitionen, Funktionalität, usw. auftreten, der Fokus dieser Version war auf Performance verbesserung,
einige kleinere fixes, und der Umstellung auf eigenes Package.

FingerPrintFn: ist eine Funktion, die in fhem.pl definiert ist. Verhindert mehrfache idente msgs (innerhalb 0.5 sec default).
Das Timeout ist konfigurierbar via global Attribut dupTimeout.

Es sind etliche Teile "toter code" auskommentiert drin, u.a. von einem Versuch einen FIFO zu realiseren um die Latenzzeiten beim read zu verbesseren.
Hat zwar funktioniert, aber nix gebracht, darum wurde die Idee verworfen. Würde auch sinnvoller in ein IO-Modul gehören.

Feedback willkommen! Bei Problemen bitte mit einem "list <device> und evtl. Log-Auszug, falls sinnvoll.
l.g.erwin

Nicht die neuste Version installiert aber mir ist gerade bei der Version 04.43 25-02-2021 etwas aufgefallen. Ich hatte autocreate gelöscht, weil ich etwas anderes probiert hatte. Dann habe ich es wieder neu definiert. Das hat dazu geführt, dass alle meine vorhandenen KNX Geräte nach und nach auf disable 1 gesetzt wurden von autocreate, obwohl diese schon definiert waren. Ist das ein Fehler in autocreate oder KNX.pm?

Hi,

Zitatdass alle meine vorhandenen KNX Geräte nach und nach auf disable 1 gesetzt wurden von autocreate

das kann im laufenden betrieb nur passieren:
1) wenn eine message für das device/ga vom bus kommt 
UND
2) die intenen strukturen den betreffenden GA nicht finden können.... $modules{KNX}{defptr}{$gadCode}
dann schlägt autocreate zu!
dann müssten allerdings auch devices mit namen KNX_xxyyzz angelegt werden und diese auf disabled gesetzt werden...
vorhandene devices werden nie auf disable gesetzt (zumindest nicht in der KNX.pm).
Wenn man das disable attr löscht, mach ich ein defmod auf diesen devicenamen, um die setlist/getlist wiederherzustellen, das sollte eigenlich auch kein solches problem verursachen!

ist das im laufenden Betrieb passiert oder nach einem shutdown/restart ?
hast du das autocreate gelöscht u. neu definiert oder ignoretypes-Attr geändert ?
gibts auffälliges im Log?

ich werde versuchen, das nachzustellen...

Lass mich mal überlegen :D. Autocreate war gelöscht und seit dem gab es auf jeden Fall restarts. Dann habe ich es neu definiert und einen restarts gemacht. Daraufhin sind natürlich die ersten Nachrichten gekommen und jedes Device, dass eine Nachricht bekommen hat wurde auf disable 1 gesetzt.

Das das nicht passieren darf dachte ich mir. Es wurden auch keine Geräte neu angelegt, sondern die vorhandenen haben das Attribute bekommen. Wo der Fehler jetzt liegt kann ich dir aktuell nicht sagen. War auch verwundert.

Hi zusammen,

ich habe hier ein Problem und weiss nicht was es verursacht hat. Ich bekomme seit 2 Tagen lauter fehler.

vielleicht habt Ihr eine Idee

2021-04-23 22:47:00 KNXTUL knx UNKNOWNCODE C01064w08709440c6a00
2021-04-23 22:47:00 KNXTUL knx UNKNOWNCODE C01064w08713441a5200
2021-04-23 22:47:00 KNXTUL knx UNKNOWNCODE C01064w0871b2c36
2021-04-23 22:47:00 KNXTUL knx UNKNOWNCODE C01064w0871c41ecf800
2021-04-23 22:47:00 KNXTUL knx UNKNOWNCODE C01064w0872e2f91
2021-04-23 22:47:00 KNXTUL knx UNKNOWNCODE C01064w0872f42b57800
2021-04-23 22:47:00 KNXTUL knx UNKNOWNCODE C01064w0873942f99800
2021-04-23 22:47:00 KNXTUL knx UNKNOWNCODE C01064w0873ac2ab6400
2021-04-23 22:47:01 KNXTUL knx UNKNOWNCODE C01064w08709440ebc00
2021-04-23 22:47:01 KNXTUL knx UNKNOWNCODE C01064w08713441c9200
2021-04-23 22:47:01 KNXTUL knx UNKNOWNCODE C01064w08714c380c200
2021-04-23 22:47:01 KNXTUL knx UNKNOWNCODE C01064w08727c2516400
2021-04-23 22:47:01 KNXTUL knx UNKNOWNCODE C0ff1fw0946400000000
2021-04-23 22:47:01 KNXTUL knx UNKNOWNCODE C01003w09415302f363838202020200000000000
2021-04-23 22:47:02 KNXTUL knx UNKNOWNCODE C01064w08709440cc600
2021-04-23 22:47:02 KNXTUL knx UNKNOWNCODE C01064w08713441a6c00
2021-04-23 22:47:02 KNXTUL knx UNKNOWNCODE C0120aw091000000
2021-04-23 22:47:02 KNXTUL knx UNKNOWNCODE C01064w08714c37e0c00
2021-04-23 22:47:02 KNXTUL knx UNKNOWNCODE C01064w0872f42b31000
2021-04-23 22:47:03 KNXTUL knx UNKNOWNCODE C01378w0970315ff
2021-04-23 22:47:03 KNXTUL knx UNKNOWNCODE C01064w08726426f1400
2021-04-23 22:47:03 KNXTUL knx UNKNOWNCODE C01064w0872f42b7fc00
2021-04-23 22:47:03 KNXTUL knx UNKNOWNCODE C01064w0873942fcc000
2021-04-23 22:47:03 KNXTUL knx UNKNOWNCODE C01064w0873ac2ad5000

hier noch ein auszug aus dem fhem log

2021.04.23 22:30:40 5: RawMessage read: 2900bcd0106447490300804446
2021.04.23 22:30:40 5: Message read - CtrlByte: 11010000 Source: 1064 Dest: 4749 Data: 00804446
2021.04.23 22:30:40 5: knx: dispatch C01064w087494446
2021.04.23 22:30:40 3: knx: Unknown code C01064w087494446, help me!
2021.04.23 22:30:40 5: KNXTUL - Read started
2021.04.23 22:30:40 5: RawMessage read: 2900bcc012024c1605008044315400
2021.04.23 22:30:40 5: Message read - CtrlByte: 11000000 Source: 1202 Dest: 4c16 Data: 008044315400
2021.04.23 22:30:40 5: knx: dispatch C01202w0941644315400
2021.04.23 22:30:40 3: knx: Unknown code C01202w0941644315400, help me!
2021.04.23 22:30:41 5: KNXTUL - Read started
2021.04.23 22:30:41 5: RawMessage read: 2900bcd01064471b0300802c36
2021.04.23 22:30:41 5: Message read - CtrlByte: 11010000 Source: 1064 Dest: 471b Data: 00802c36
2021.04.23 22:30:41 5: knx: dispatch C01064w0871b2c36
2021.04.23 22:30:41 3: knx: Unknown code C01064w0871b2c36, help me!
2021.04.23 22:30:41 5: KNXTUL - Read started
2021.04.23 22:30:41 5: RawMessage read: 2900bcd0106447390500804307f400
2021.04.23 22:30:41 5: Message read - CtrlByte: 11010000 Source: 1064 Dest: 4739 Data: 00804307f400
2021.04.23 22:30:41 5: knx: dispatch C01064w087394307f400
2021.04.23 22:30:41 3: knx: Unknown code C01064w087394307f400, help me!
2021.04.23 22:30:41 5: KNXTUL - Read started
2021.04.23 22:30:41 5: RawMessage read: 2900bcd01064473a050080c2b6a800
2021.04.23 22:30:41 5: Message read - CtrlByte: 11010000 Source: 1064 Dest: 473a Data: 0080c2b6a800
2021.04.23 22:30:41 5: knx: dispatch C01064w0873ac2b6a800
2021.04.23 22:30:41 3: knx: Unknown code C01064w0873ac2b6a800, help me!
2021.04.23 22:30:41 5: changing value, ATTR: verbose, VALUE: 1
2021.04.23 22:32:01 3: GAEBUS opening ebus1 device 192.168.3.226(8888)
2021.04.23 22:32:01 3: GAEBUS device opened (ebus1)


grüße
Tom

Hi tom1607!

ZitatIch bekomme seit 2 Tagen lauter fehler

Die Frage ist: Was hast du vor 2 Tagen geändert?
Ich kann in deinen Logs  nicht wirklich einen Fehler entdecken.
Die Messages besagen lediglich, dass du etliche devices nicht in FHEM definiert hast!
z.b: 8/7/9 , 8/7/19, 8/7/27, 8/7/28, 8/7/30, usw....

nützlich fürs deguggen wäre ein list <device> vom KNXTUL
und eine Beschreibung deines environments... (welches KNX-GW, KNXD ja/nein, autocreate ja/nein)...
passiert das während FHEM start oder im laufenden Betrieb?
mach bitte auch ein list eines beliebigen KNX devices.

l.g. erwin

Hallo Erwin,

ich habe das Update gemacht und erhalte ebenfalls nur noch Fehler. Direkt nach "shutdown restart". Es ist keine Kommunikation mehr möglich.

Im Log finde ich wenig.
2021.04.24 16:25:11.929 3: KNXTUL opening KNX
2021.04.24 16:25:11.929 3: KNXTUL device opened
2021.04.24 16:25:19 1: FHEM::Meta::__GetUpdatedata: ERROR: FHEM/10_KNX.pm belongs to source repository "fhem". Ignoring identical file name from source repository KNXevolution
2021.04.24 16:25:27.185 3: KNX: Unknown code C01201w0010200fa, help me!
2021.04.24 16:25:27.446 3: KNX: Unknown code C01001w0470a00000000, help me!
2021.04.24 16:25:27.502 3: KNX: Unknown code C01201w0010200f0, help me!
2021.04.24 16:25:27.503 3: KNX: Unknown code C01201w0010200e6, help me!
2021.04.24 16:25:27.505 3: KNX: Unknown code C01201w0010200dc, help me!
2021.04.24 16:25:27.506 3: KNX: Unknown code C01201w00215ff, help me!
2021.04.24 16:25:27.507 3: KNX: Unknown code C01001w0470b43bd0000, help me!
...

Ich habe die vorherige Version direkt wieder eingespielt.

Ich habe ein list von einem Device gemacht, vor und nach Update, dann Unterschiede gesucht:

Folgende Zeile fehlt nach dem Update:
FVERSION   10_KNX.pm:?/2021-03-03 UNSTABLE

Weitere Unterschiede:

- Zeile NOTIFYDEV, vor zu nach dem Update
NOTIFYDEV  global,TYPE=KNX
NOTIFYDEV  global,KNX_0101000

- es ist eine nosuffix-DEF: nach dem Update scheint dies nicht mehr so:
RDNAMEGET  getG1
RDNAMEPUT  putG1
RDNAMESET  setG1


Hallo GammaTwin,

sehr seltsam!!!! Bei mir läuft die version ohne probleme auf 2 verschiedenen systemen! (einmal mit TUL- einmal mit KNXTUL-IOmodul)
ich hab mir jetzt nochmal die version vom git heruntergeladen, und kann das nicht nachstellen!

die FHEM::Meta:: Fehlermeldung ist "normal", kommt vom installer-modul, das externe repositories nicht mag....(ist im ersten post erwähnt,glaube ich)
FVERSION: ebenfalls installer-modul hab ich jetzt auch nicht mehr...
NOTIFYDEV: ist korrekt, hab ich geändert, wäre auch richtig, falls dieses device wirklich KNX_0101000 heisst!

nosuffix def: das ist interessant, kannst du mir ein list von diesem device posten?
evtl. geht da beim define was schief  (während restart)?
es reicht mir ein list vom funktionierenden system, ich nehme an, du bist auf die 4.43 zurückgegangen?
l.g. erwin

Hallo Erwin,

ich habe ein Update vom fhem gemacht.

Ich habe einen Enertex IP Secure Router. Ich betreibe den im Broadcastmodus ohne EIBD.


Internals:
   Clients    KNX
   DEF        1.1.253
   DeviceAddress 011fd
   FD         5
   FUUID      5d060185-f33f-f7bf-1d0f-45ec38e9eeb3ee5c
   HAS_IO::Socket::Multicast 1
   IPAddress  224.0.23.12
   NAME       knx
   NR         28
   PARTIAL   
   Port       3671
   RAWMSG     C01202w0941644359000
   REFUSED   
   STATE      Initialized
   TYPE       KNXTUL
   UseDirectConnection 0
   knx_MSGCNT 833550
   knx_TIME   2021-04-24 20:46:37
Attributes:
   room       System--KNX
   verbose    1


Das ist ein Wert der nicht mehr aktualisiert wird. Ich sehe in der ETS das das Telegramm auf dem Bus ist aber das Device wird nicht aktualisiert.


Internals:
   DEF        8/7/8:dpt9.021
   DEVNAME    StromK1
   FIRSTGADNAME g1
   FUUID      5d05e087-f33f-f7bf-24b6-e088684a32456f33
   FVERSIONE  04.52 13-04-2021
   GETSTRING  g1:noArg
   IODev      knx
   NAME       StromK1
   NOTIFYDEV  global,StromK1
   NR         87
   NTFY_ORDER 50-StromK1
   SETSTRING  g1:slider,-670760,13415,670760
   STATE      29552.64 mA
   TYPE       KNX
   GADDETAILS:
     g1:
       CODE       08708
       GROUP      8/7/8
       MODEL      dpt9.021
       NO         1
       OPTION     
       RDNAMEGET  getG1
       RDNAMEPUT  putG1
       RDNAMESET  setG1
       SETLIST    :slider,-670760,13415,670760
   GADTABLE:
     08708      g1
   READINGS:
     2021-04-22 20:46:44   getG1           29552.64 mA
     2021-04-22 20:46:44   last-sender     1.0.100
     2021-04-22 20:46:44   state           29552.64 mA
Attributes:
   IODev      knx
   room       Smartmeter,System--KNX


Ich hoffe das hilft weiter.

grüße
Tom

Grüße,

ich bin auf 4.43 zurückgegangen. Das Device heißt "KNX_0101000".

Internals:
   DEF        1/1/0:dpt1.001:g1:set:nosuffix 1/2/0:dpt1.001:g2:get:nosuffix
   DEVNAME    KNX_0101000
   FIRSTGADNAME g1
   FVERSION   10_KNX.pm:?/2021-03-03 UNSTABLE
   FVERSIONE  04.43 25-02-2021
   GETSTRING  g2:noArg
   IODev      KNX
   NAME       KNX_0101000
   NOTIFYDEV  global,TYPE=KNX
   NR         330
   NTFY_ORDER 50-KNX_0101000
   SETSTRING  on:noArg off:noArg g1:off,on
   STATE      off
   TYPE       KNX
   GADDETAILS:
     g1:
       CODE       01100
       GROUP      1/1/0
       MODEL      dpt1.001
       NO         1
       OPTION     set
       RDNAMEGET  g1
       RDNAMEPUT  g1
       RDNAMESET  g1
       SETLIST    :off,on
     g2:
       CODE       01200
       GROUP      1/2/0
       MODEL      dpt1.001
       NO         2
       OPTION     get
       RDNAMEGET  g2
       RDNAMEPUT  g2
       RDNAMESET  g2
       SETLIST    :off,on
   GADTABLE:
     01100      g1
     01200      g2
   READINGS:
     2021-04-24 16:40:49   g2              off
     2021-04-24 16:40:49   last-sender     1.0.2
     2021-04-24 16:40:49   state           off
Attributes:
   IODev      KNX

Sorry GammaTwin & tom1607 und alle anderen!

nachdem ich euer Problem nicht nachstellen kann, und im Moment auch keine idee habe woran es liegen könnte,
werde ich die Version E04.43 wieder aufs GIT stellen.
Zudem bin ich die nächsten Wochen auf Urlaub, zwar mit Internet aber ohne test-equipment.
Ich befürchte das Problem  ist "environment"  abhängig (perl-version, autocreate-definition, ???). Wenn also jemand die Version E04.52 ohne Probleme
an Laufen hat, bitte um Feedback, damit wir der Sache näher kommen können.
l.g. erwin 

Erstmal Urlaub machen und dann in Ruhe schauen, die E04.43 läuft ja. Welchen Bug wolltest du denn in der neueren Version lösen? Hatte es bisher zeitlich noch nicht geschafft ein Update zu machen und werde es jetzt ja auch lassen.

Edit:
Habe das Changelog gefunden. Vergiss meine Frage.

Hallo zusammen,

ich wünsche auch einen schönen Urlaub.

Ich wollte nur kurz feedback geben, ich habe die alte Version wieder eingespielt und es läuft wieder.

Wenn du aus dem Urlaub zurück bist können wir gerne mal die Sachen im Details analysieren ich würde halt alle Logs die benötigt werden zur Verfügung stellen.

Aber bis dahin geniess deinen Urlaub ist in der heutigen Zeit eh schwierig.

grüße
Tom

Urlaub ist wichtig :)

Genießen :)

Grüße,

ich habe seit langem mal wieder eine neue Gruppenadresse angelegt. In der ETS diese abgefragt, damit in FHEM das Device anlegt. Das klappt auch, Device ist disabled.

Was fehlt ist der zweite Filelog-Device, denn ich sonst immer angelegt bekomme. Am autocreate habe ich nichts geändert.
Internals:
   FUUID      5e3fe740-f33f-48fd-ac73-490de8f887f717cc
   FVERSION   98_autocreate.pm:0.237270/2021-02-12
   NAME       autocreate
   NOTIFYDEV  global
   NR         375
   NTFY_ORDER 50-autocreate
   STATE      active
   TYPE       autocreate
   received:
Attributes:
   disable    0
   filelog    ./log/autocreate/%NAME-%Y.log

Könnte es mit dem "autodisable" zu tun haben?

Hi,

ZitatKönnte es mit dem "autodisable" zu tun haben?

nein, es wird kein Filelog angelegt.
Begründung: Ich gehe davon aus, dass das "neue" device einen "sprechenden" namen bekommt (rename...) und damit die filelog definition obsolet wäre.
ich habe mir für solche Fälle ein "KNX_default_FileLog" gebaut, beschrieben in der cmdref:
If enabled, the module autocreate is creating a new definition for any unknown sender. The device itself will be disabled until you added a DPT to the definition and clear the disabled attribute.
The name will be KNX_nnmmooo where nn is the line adress, mm the area and ooo the device. No FileLog or SVG definition is created for KNX-devices by autocreate.
Use for example define <name> FileLog <filename> KNX_.* to create a single FileLog-definition for all KNX-devices created by autocreate.
l.g. erwin

Ist das Problem mit inactive und dem damit verbundenen ungewollten disable des Device eigentlich behoben? Habe die E04.43 bei mir aktuell laufen. Das müsste doch die stabilste nach der verbuggten Version sein, die Probleme gemacht hat, oder?

Ist das Problem mit inactive und dem damit verbundenen ungewollten disable ...
Sorry, das ist in der E04.43 noch nicht gefixt...
Nachdem ich die Probleme mit E04.52 bisher nicht nachstellen konnte, werde ich nächste Woche eine Version aufs GIT stellen, die etwa 50% der Änderungen (vgl. E04.52) enthält
und euch um Tests bitten. Der "inactive" fix ist in der Version von nächste Woche enthalten.
l.g. erwin

Alles klar, das erklärt das ein oder andere Verhalten bei mir. Mach dir bitte keinen Stress deswegen, war eben nur unsicher, wie der Stand in der Version war und konnte nicht verstehen warum ein Device sich komisch verhalten hat.

Hi,
Version 04.60 ist am GIT.
bitte um Test und Feedback.
Änderungen:
-change: 50% of the changes of the unsucessful Vers. 04.52
        IsDisabled when state = inactive
        cleanup, replaced ok-dialog on get-cmd by "err-msg"
        docu correction
        fixed KNX_replaceByRegex
        replace eval by AnalyzePerlCommand
        added FingerPrintFn, fix DbLog_split
Nachdem ich den Fehler mit der Version 04.52 nicht nachstellen konnte, bitte um VORSICHT!
Evtl. die bisherige version vor dem update kopieren/sichern!
l.g. erwin

Update eingespielt. Kommunikation ist diesmal möglich. Werde beobachten...


Habe wieder folgendes Problem:

Zitat von: GammaTwin am 11 Februar 2021, 19:09:45
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?

:-\

Bin wieder zurück gegangen. Hattest Du ja schon mal gelöst :)

Wollte heute Abend testen aber dann warte ich auch noch bis das gefixed ist, sonst klappen meine DOIFs auch nicht :)

Hi GammatTwin & Amenophis86,
fix ist am GIT: Version 04.62

wieder eingespielt :) Fix hat funktioniert. Beobachtung läuft wieder.

Habs auch gerade eingespielt und werde mal sehen, ob ich was finde.

Also ich konnte bisher keine Probleme feststellen. Will die Tage nochmal autocreate wieder definieren und schauen, ob das Problem noch besteht, dass alles auf disable 1 gesetzt wird aber da brauche ich Zeit zu um den Fehler abzufangen, wenn er kommen sollte.

Hi,
das sind ja good news!
lasst euch ruhig Zeit mit dem Testen, ich bin die nächste nächste Woche noch verfügbar, aber vom 5.-12.6. wieder weg, und erst nachher wird's die nächsten (geplanten) changes geben.
l.g.  und danke fürs testen
erwin

Grüße,

mir ist etwas aufgefallen. Meine Fensterzustände stimmen nicht mehr.

Kann es sein, dass Wiederholungen irgendwie ignoriert werden? In einer bestimmten Zeit?

Zu Erklärung, wie die Fensterzustände ermittelt werden. Jede Griffposition sendet 2 Zustände:
false,false: Griff unten - geschlossen
true,true: Griff seitlich - offen
true,false: Griff oben - gekippt
Im KNX-System erzeugt eine Logik dann die Zustände "offen: true|false", "gekippt: true|false". Geschlossen gibt es nicht als Zustand, kann aber angenommen werden, wenn "offen" und "gekippt" false sind.

In Summe senden also 4 Gruppenadressen "Zustand 1", "Zustand 2", "offen", "gekippt". Da die Logik auf jede Änderung der "Zustände" reagiert, werden bei jeder Bewegung des Griffes 6 Telegramme gesendet:
Zustand 1
offen
gekippt
Zustand 2
offen
gekippt

Schließe ich das gekippte Fenster, bewege ich den Griff über offen, es werden also 12 Telegramme gesendet - in weniger als 400 ms.
#erste 90 Grad Griffdrehung
Zustand 1
offen
gekippt
Zustand 2
offen
gekippt
#zweite 90 Grad Griffdrehung
Zustand 1
offen
gekippt
Zustand 2
offen
gekippt

Soweit zudem, was schon immer auf dem Bus passierte. Im FHEM werden nur die beiden ersten Telegramme pro Gruppenadressen "wahrgenommen":
#erste 90 Grad Griffdrehung
Zustand 1
offen
gekippt
Zustand 2
offen
gekippt
#zweite 90 Grad Griffdrehung
Zustand 1
Zustand 2
Das dritte und vierte Telegramm von "offen" und "gekippt" gibt es nicht in FHEM und diese erscheinen nicht im Log.

Das kann ich mit jedem Fenster im Haus nachstellen.

Hi GammaTwin,

richtig 2 gleiche KNX Telegramme (innerhalb 500ms) werden ignoriert.
Gleich heisst: GA-Adresse und value ist ident
Das ist eine Funktion in fhem.pl, die ich in KNX.pm nutze.
Die Zeit ist konfigurierbar via global Attribut dupTimeout (default 500ms) siehe: https://wiki.fhem.de/wiki/DevelopmentModuleIntro - suche nach Fingerprint

Vorschlag: kommentiere die Zeile:       $hash->{FingerprintFn}  = "KNX_FingerPrint"; aus, mach einen shutdown restart
(sollte Zeile 288 sein)
Wenn das Problem weg ist, haben wir die Ursache gefunden....
l.g. erwin

Ich hänge mich mal mit dran, da ich eine ähnliche Frage habe. Gibt es auch eine Begrenzung in die andere Richtung? Ich habe ein Script für meinen Müllkalender bei dem im schlechtesten Fall bis zu 12 Telegramm furch eine for-Schleife direkt nacheinander von FHEM gesendet werden. Manchmal scheinen aber nicht alle auf dem BUS durch zu gehen.

Hi Amenophis86,

nein die Funktion gibts nur für den Empfang vom Bus. Ursprünglich hat Rudi das für die diversen Funkprotokolle implementiert, die grundsätzlich alles mehrfach senden...
Ich habs deßhalb implemetiert, weil ich (entgegen der dringenden Empfehlung) einen KNX-Router und KNXD mit Multicast testweise aktiviert habe und damit alle Telegramme mehrfach empfangen wurden.
l.g. erwin

Alles klar, dann werde ich da mal weiter suchen. Kann mir vorstellen, dass es einfach für den Bus zu viel ist, wenn da so viel auf einmal raus gehauen wird. Aber werde mal weiter testen.

Ich bekomme seit dem neuesten Update gestern keine Daten mehr ins FHEM, senden kann ich lustigerweise noch.


Nach Restore auf 10_KNX.pm FVERSIONE  04.43 25-02-2021 geht es wieder.

Hi Hauswart,

kanst du bitte das IO-Device auf verbose 5 setzen und nach Log-Mgs schauen, die mit KNX_parse... beginnen?
l.g. erwin

Zitat von: erwin am 28 Mai 2021, 08:46:44
Hi GammaTwin,

richtig 2 gleiche KNX Telegramme (innerhalb 500ms) werden ignoriert.
Gleich heisst: GA-Adresse und value ist ident
Das ist eine Funktion in fhem.pl, die ich in KNX.pm nutze.
Die Zeit ist konfigurierbar via global Attribut dupTimeout (default 500ms) siehe: https://wiki.fhem.de/wiki/DevelopmentModuleIntro - suche nach Fingerprint

Vorschlag: kommentiere die Zeile:

Code Auswählen Erweitern

       $hash->{FingerprintFn}  = "KNX_FingerPrint"; aus, mach einen shutdown restart
(sollte Zeile 288 sein)
Wenn das Problem weg ist, haben wir die Ursache gefunden....
l.g. erwin

Mit der auskommentierten Zeile funktioniert es. Damit haben wir die Ursache.

Dies bedeutet aber, das identische Telegramme verworfen werden, auch wenn in der Zwischenzeit ein anderer Zustand der GA gesendet wird. Es wird also nicht geprüft, ob es eine Wiederholung ist. Das ist aber doch nicht in Ordnung, oder?

In meinem Fall und vereinfacht auf "offen":
#erste 90 Grad Griffdrehung
offen: false (Zwischen-Status, da nur Zustand1 aktualisiert)
offen: true (korrekter Status)
#zweite 90 Grad Griffdrehung
offen: false (Zwischen-Status) - wird verworfen, da identisches Telegramm
offen: false (korrekter Status) - wird verworfen, da identisches Telegramm
Es bleibt offen:true stehen.

Hi GammaTwin,

JA, alles richtig analysiert, es wird nicht geprüft ob dazwischen eine andere msg für diese GA gekommen ist mit einem anderen value.
also eine Folge GA=0, GA=1, GA=0 (innerhalb duptimeout) wird die letzte msg verworfen!
Soweit ich die funktion in fhem.pl verstehe, wird jede msgs gegen einen Buffer gecheckt, ob eine idente msg im buffer ist, die nicht älter als dupTimeout ist.

Ich werde die Funktion einfach rausnehmen, ist für KNX nicht wirklich relevant, ausser man macht so "unsupported" Dinge wie ich....
PS: der zweite Grund, warum ich mit dieser funktion gespielt hab, war dass die SONOFF (Tasmota)-KNX implementation jede msg grundsätzlich 3mal übers WLAN schickt. - kann man aber im Tasmota abstellen....
l.g. erwin

Das Problem mit autocreate ist immer noch gegeben. Was habe ich gemacht:

Ich hatte bereits einige KNX Devices definiert.
- Autocreate wurde vor einiger Zeit gelöscht
- inzwischen gab es auch mehrfache restarts
- eben gerade autocreate neu definiert define autocreate autocreate
- restarte von FHEM
- neue KNX GA werden erkannt, die entsprechenden Device angelegt und disable auf 1 gesetzt

Problem:
- alle vorhandenen KNX Device werden beim ersten empfang eines Telegrams seit der Definition von autocreate auch auf disable 1 gesetzt

Warum das so ist kann ich nicht sagen. Wenn ich irgendwas loggen soll um es zu testen oder den Quellcode irgendwo anpassen muss, dann müsst ihr mir sagen wo :)

Edit:
Ach es gibt auch keinen Hinweis im Log, dass bei den Geräten disable auf 0 gesetzt wurde. Lediglich anhand es roten Fragezeichen habe ich es gemerkt und wenn ich dann in die Geräte schaue sehe ich, dass disable auf 1 sitz. Bei neuen Geräten kommt die Meldung im Log, dass diese auf disabel 1 gesetzt wurden und man die korrekte dpt definieren soll.

Hi Amenophis86,

nachstellen kann ich das nicht, aber deine Problembeschreibung deutet darauf hin, dass msgs vom BUS kommen, bevor FHEM mit dem starten (=erstellen aller device-definitionen) fertig ist.
Wenn das so ist, sollten devices mit namen KNX_xxyyzzz angelegt werden - disabled! - was ja passiert, wie du schreibst, wenn fhem läuft und ein "neues" device was sendet.

um das zu testen, bitte mach folgendes:
ändere die sub KNX_Parse (nur eine zeile):

sub KNX_Parse {
        my $iohash = shift; # this is IO-Device hash !
        my $msg = shift;
        my $ioName = $iohash->{NAME};

        return q{} if (! init_done); ### das ist neu !!! ### ignore msgs bevor fhem startup complete
        return q{} if (IsDisabled($ioName) || IsDummy($ioName)); # IO - device is disabled or dummy

dann natürlich shutdown-restart...
PS: Falls das wirklich das Problem ist, sollte das (eigentlich) schon im IO-modul (TUL/KNXTUL) abgefangen werden......
l.g. erwin

scheint irgendwo ein Fehler zu sein, bekomme beim neustart nach ändern der Datei den Fehler:

Bareword "init_done" not allowed while "strict subs" in use at ./FHEM/10_KNX.pm line 948, <$fh> line 256.

2021.06.01 20:02:19 0: Bareword "init_done" not allowed while "strict subs" in use at ./FHEM/10_KNX.pm line 948, <$fh> line 256.

und das sehr oft im Log, da er immer wieder die 10_KNX.pm wohl neu einliest.

Ich glaube übrigens auch nicht, dass es am einlesen liegt. Das disable setzen von bereits bekannten Geräten kommt noch lange nach dem Neustart, wenn ich das richtig sehe. Also stell es dir so vor, dass FHEM bereits läuft eine GA nach dem Start eine Nachricht sendet und autocreate es dann auf disabel 1 setzt, obwohl das Gerät schon vorhanden war.

Ich wüsste auch nicht, dass ich irgendwas geändert habe, was das beeinflussen könnte bzw. zu einer anderen Installation anders wäre, dass du es nicht nachstellen kannst.

Ich glaube ich habe den Fehler gefunden. Ich habe mir nochmal den Eventmonitor angeschaut um zu schauen was passiert und dabei ist mir was aufgefallen. Ich habe eine zweite FHEM Instanz und greife dort die Daten mittels RFHEM FHEM2FHEM ab. Das sorgt dafür, dass Events von FHEM2 als eigene Events in FHEM1 erkannt werden. Wenn nun eine GA in FHEM2 nicht definiert ist, dann bekommt FHEM1 auch die Meldung, dass das Device noch nicht vorhanden ist, obwohl es das ist. Dadurch wird glaube ich das Device in FHEM1 auf disable gesetzt. Ich kann es noch nicht sicher sagen aber es sieht auf den ersten schnellen Blick so aus, als ob es das sein könnte.

Edit:
Ja, sieht schwer danach aus, dass das Problem gefunden ist. Setzte ich RFHEM FHEM2FHEM auf disable 1 bleiben die Probleme aus, lösche ich disabel werden die Device nach und nach deaktiviert.

Hi,
FHEM2FHEM hab ich nicht im Einsatz, aber ich denke es müsste möglich sein, die UNDEFINED events zu unterdrücken ?
Stichwort excludeEvents ? Oder in FHEM2 kein autocreate für KNX-devices...

hab schon mit exclude Events angefangen zu arbeiten gestern Abend und konnte wohl auch den Fehler damit unterdrücken. Nur vergessen hier noch Rückmeldung zu geben. Aber dank dir für den Hinweis :)

Hallo,
ich habe gestern die neue Version eingespielt und heute wieder einen Ausfall gehabt. für den Zeitraum von ca.2 stunden keine Werte bekommen. danach lief es wieder. ich werde weiter beobachten und bescheid geben.

grüße
Thomas

Zitat von: tom1607 am 16 Juni 2021, 19:48:13
Hallo,
ich habe gestern die neue Version eingespielt und heute wieder einen Ausfall gehabt. für den Zeitraum von ca.2 stunden keine Werte bekommen. danach lief es wieder. ich werde weiter beobachten und bescheid geben.

Wahrscheinlich der gleiche Fall wie bei mir, wenn du die Version noch aktiv hast, folgendes ausprobieren:

Zitat von: erwin am 28 Mai 2021, 12:20:45
Hi Hauswart,

kanst du bitte das IO-Device auf verbose 5 setzen und nach Log-Mgs schauen, die mit KNX_parse... beginnen?
l.g. erwin

Hi Hauswart & Tom1607!

Gibt es Erkentnisse / Debug-Ergebnisse, die ich in der nächsten Version berücksichtigen kann ?
Ich möchte die nächste Version ab 20.7. hochladen. Die läuft jetzt bei mir seit 6 Wochen stabil.
l.g. erwin

Hallo,
wenn ich in der FHEM Zeile:
version 10_KNX.* absetze bekomme ich:

ZitatFile      Rev   Last Change

No Id found for 10_KNX.pm

Sollte da nicht die Version angezeigt werden?
Wenn nicht wie schaue ich mir an welche Version ich im Moment benutze?

Wenn ich mich per SSH auf den PI verbinden und dort:
/opt/fhem/FHEM $ cat 10_KNX.pm | more

Sehe ich als letze Zeile im, sagen wir Header:

Zitat# MH  20210521 E04.62 DbLog_split replace regex by looks_like_number
#              fix readingsnames "gx:...:nosuffix"

Ein list 10_KNX.pm geht auch nicht und sagt einfach No device named 10_KNX.pm found
Gruß
Christian

Hi Christian!

Sorry, war wieder ein paar Tage auf Urlaub...
Zu deinen Fragen:

1) Version - No Id found:
    kommt daher, weil das Modul nicht im SVN eingecheckt ist. Sobald das Modul einen "offiziellen status" hat, wird das auch funktionieren. Wobei mit diesem Kommando nicht die Version, sondern die Revision ausgegeben wird, das ist SVN spezifisch!

2) cat 10_KNX.pm
    Das sind Kommentare, bzw. eine History of changes, wenn das die letzte Kommentarzeile im Header ist, dann ist das die richtige Version !

3) ein list 10_KNX.pm geht sicher nicht, das list command braucht ein device als argument - aber kein modul

4) Die aktuell verwendete Version herausfinden:
    4a) im detail-view eines beliebigen KNX-device

    4b)  list <device>
    das schaut dann so aus:
Internals:
   DEF        5/3/86:dpt1:set:nosuffix 5/3/90:dpt1:get:nosuffix
   DEVNAME    Dach_Steckdose
   FIRSTGADNAME g1
   FUUID      5ff8af0a-f33f-5c4d-152c-516251257777ca32
   FVERSIONE  04.65 xx-05-2021
   GETSTRING  g2:noArg
   IODev      myKNXD
   NAME       Dach_Steckdose
   NOTIFYDEV  global,Dach_Steckdose
   .....

  jeweils unter  FVERSIONE findest du die Version. Das ist jetzt temporär, sobald das Modul im SVN ist, geht ein version 10_KNX.pm....
l.g. erwin

Neue Version 04.66 am Github!

diese Version läuft seit ca. 2 Monaten bei mir.
Änderungen:
  own package FHEM::KNX
  remove Fingerprint Function
  new dpts: dpt7.600, dpt9.029, dpt9.030

Probleme bitte mit list device und/oder log posten.
danke erwin

Test läuft :)

Die Version läuft bei mir derzeit unauffällig im Produktivbetrieb.

Läuft bei mir auch schon seit ein paar Tagen ohne Probleme