Autor Thema: [obsolet - Modul ist im SVN - siehe Forum #12582] 10_KNX.pm Weiterentwicklung  (Gelesen 15686 mal)

Offline GammaTwin

  • Full Member
  • ***
  • Beiträge: 142
Antw:10_KNX.pm Weiterentwicklung
« Antwort #60 am: 11 Februar 2021, 22:26:00 »
Danke, eingespielt und funktioniert.

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

Offline lichtimc

  • Full Member
  • ***
  • Beiträge: 109
    • davitech.casa
Antw:10_KNX.pm Weiterentwicklung
« Antwort #61 am: 14 Februar 2021, 00:58:38 »
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...

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 622
Antw:10_KNX.pm Weiterentwicklung
« Antwort #62 am: 14 Februar 2021, 11:33:43 »
Hi lichtimc,
Zitat
Wä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,
Zitat
Berechnungen 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
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline lichtimc

  • Full Member
  • ***
  • Beiträge: 109
    • davitech.casa
Antw:10_KNX.pm Weiterentwicklung
« Antwort #63 am: 14 Februar 2021, 12:03:02 »
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.

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 622
Antw:10_KNX.pm Weiterentwicklung
« Antwort #64 am: 14 Februar 2021, 14:16:19 »
Zitat
weil 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
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2927
  • Anti-Statement befreite Zone ;)
Antw:10_KNX.pm Weiterentwicklung
« Antwort #65 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.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Offline lichtimc

  • Full Member
  • ***
  • Beiträge: 109
    • davitech.casa
Antw:10_KNX.pm Weiterentwicklung
« Antwort #66 am: 14 Februar 2021, 21:16:52 »
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...
« Letzte Änderung: 14 Februar 2021, 21:18:25 von lichtimc »

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 622
Antw:10_KNX.pm Weiterentwicklung
« Antwort #67 am: 15 Februar 2021, 19:11:15 »
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
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline lichtimc

  • Full Member
  • ***
  • Beiträge: 109
    • davitech.casa
Antw:10_KNX.pm Weiterentwicklung
« Antwort #68 am: 15 Februar 2021, 19:20:04 »
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!
« Letzte Änderung: 15 Februar 2021, 19:22:14 von lichtimc »

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2927
  • Anti-Statement befreite Zone ;)
Antw:10_KNX.pm Weiterentwicklung
« Antwort #69 am: 15 Februar 2021, 20:39:59 »
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.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 622
Antw:10_KNX.pm Weiterentwicklung
« Antwort #70 am: 16 Februar 2021, 09:08:06 »
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
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2927
  • Anti-Statement befreite Zone ;)
Antw:10_KNX.pm Weiterentwicklung
« Antwort #71 am: 18 Februar 2021, 19:08:09 »
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.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 622
Antw:10_KNX.pm Weiterentwicklung
« Antwort #72 am: 19 Februar 2021, 09:57:26 »
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
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2927
  • Anti-Statement befreite Zone ;)
Antw:10_KNX.pm Weiterentwicklung
« Antwort #73 am: 19 Februar 2021, 10:25:16 »
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?
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 622
Antw:10_KNX.pm Weiterentwicklung
« Antwort #74 am: 19 Februar 2021, 11:55:01 »
Zitat
Woran 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
FHEM aktuell auf RaspberryPI mit Busware ROT / Weinzirl IP731
Maintainer 10_KNX.pm
CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT
1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT2, KNX, SONOFF, mySENSORS,...