Autor Thema: 10_KNX.pm Weiterentwicklung  (Gelesen 1514 mal)

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1611
Antw:10_KNX.pm Weiterentwicklung
« Antwort #15 am: 27 Dezember 2020, 23:01:04 »
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
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Offline erwin

  • Full Member
  • ***
  • Beiträge: 414
Antw:10_KNX.pm Weiterentwicklung
« Antwort #16 am: 28 Dezember 2020, 15:43:16 »
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
 
FHEM 5.7 auf RaspberryPI mit Busware ROT
CUNO2 V 1.44 CUNO868 SLOWRF - HMS100xx, FS20, FHT
1-Wire über ROT - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT-DEVICES, KNX - EIBD

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1611
Antw:10_KNX.pm Weiterentwicklung
« Antwort #17 am: 28 Dezember 2020, 17:06:56 »
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
« Letzte Änderung: 28 Dezember 2020, 17:08:51 von JoeALLb »
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Offline erwin

  • Full Member
  • ***
  • Beiträge: 414
Antw:10_KNX.pm Weiterentwicklung
« Antwort #18 am: 28 Dezember 2020, 18:07:53 »
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
FHEM 5.7 auf RaspberryPI mit Busware ROT
CUNO2 V 1.44 CUNO868 SLOWRF - HMS100xx, FS20, FHT
1-Wire über ROT - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT-DEVICES, KNX - EIBD

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2752
  • Anti-Statement befreite Zone ;)
Antw:10_KNX.pm Weiterentwicklung
« Antwort #19 am: 06 Januar 2021, 19:49:03 »
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.
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

  • Full Member
  • ***
  • Beiträge: 414
Antw:10_KNX.pm Weiterentwicklung
« Antwort #20 am: 07 Januar 2021, 09:34:06 »
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?
« Letzte Änderung: 08 Januar 2021, 18:57:46 von erwin »
FHEM 5.7 auf RaspberryPI mit Busware ROT
CUNO2 V 1.44 CUNO868 SLOWRF - HMS100xx, FS20, FHT
1-Wire über ROT - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT-DEVICES, KNX - EIBD

Offline Kohle77

  • Jr. Member
  • **
  • Beiträge: 60
Antw:10_KNX.pm Weiterentwicklung
« Antwort #21 am: 16 Januar 2021, 10:02:56 »
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

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1611
Antw:10_KNX.pm Weiterentwicklung
« Antwort #22 am: 16 Januar 2021, 10:07:05 »
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".
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Offline erwin

  • Full Member
  • ***
  • Beiträge: 414
Antw:10_KNX.pm Weiterentwicklung
« Antwort #23 am: 16 Januar 2021, 10:23:38 »
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.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:
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
« Letzte Änderung: 16 Januar 2021, 10:32:25 von erwin »
FHEM 5.7 auf RaspberryPI mit Busware ROT
CUNO2 V 1.44 CUNO868 SLOWRF - HMS100xx, FS20, FHT
1-Wire über ROT - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,...
MQTT-DEVICES, KNX - EIBD
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Kohle77

  • Jr. Member
  • **
  • Beiträge: 60
Antw:10_KNX.pm Weiterentwicklung
« Antwort #24 am: 16 Januar 2021, 13:49:39 »
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

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2752
  • Anti-Statement befreite Zone ;)
Antw:10_KNX.pm Weiterentwicklung
« Antwort #25 am: 16 Januar 2021, 17:36:00 »
@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
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 Kohle77

  • Jr. Member
  • **
  • Beiträge: 60
Antw:10_KNX.pm Weiterentwicklung
« Antwort #26 am: 18 Januar 2021, 08:19:16 »
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

Offline Kohle77

  • Jr. Member
  • **
  • Beiträge: 60
Antw:10_KNX.pm Weiterentwicklung
« Antwort #27 am: 18 Januar 2021, 14:12:57 »
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