10_KNX.pm Weiterentwicklung

[JoeALLb]

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.

Code: [Auswählen]

{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

[erwin]

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
 

[JoeALLb]

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

[erwin]

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

[Amenophis86]

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.

[erwin]

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

Code: [Auswählen]

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

[Kohle77]

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

[JoeALLb]

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

[erwin]

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:

Code: [Auswählen]

update delete https://raw.githubusercontent.com/erw111n/FHEM-KNX/main/controls_KNXevolution.txtdann 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:

Code: [Auswählen]

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

[Kohle77]

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

[Amenophis86]

@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

[Kohle77]

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

[Kohle77]

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 weiterhelfen?

Gruß
Christian