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

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 577
Antw:10_KNX.pm Weiterentwicklung
« Antwort #135 am: 28 Mai 2021, 15:20:04 »
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
« Letzte Änderung: 28 Mai 2021, 15:25:14 von 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,...
Zustimmung Zustimmung x 1 Liste anzeigen

Offline Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2920
  • Anti-Statement befreite Zone ;)
Antw:10_KNX.pm Weiterentwicklung
« Antwort #136 am: 01 Juni 2021, 17:50:21 »
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.
« Letzte Änderung: 01 Juni 2021, 17:52:15 von Amenophis86 »
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: 577
Antw:10_KNX.pm Weiterentwicklung
« Antwort #137 am: 01 Juni 2021, 19:48:47 »
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
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: 2920
  • Anti-Statement befreite Zone ;)
Antw:10_KNX.pm Weiterentwicklung
« Antwort #138 am: 01 Juni 2021, 20:04:14 »
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.
« Letzte Änderung: 01 Juni 2021, 20:06:52 von Amenophis86 »
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 Amenophis86

  • Hero Member
  • *****
  • Beiträge: 2920
  • Anti-Statement befreite Zone ;)
Antw:10_KNX.pm Weiterentwicklung
« Antwort #139 am: 01 Juni 2021, 20:17:34 »
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.
« Letzte Änderung: 01 Juni 2021, 20:26:46 von Amenophis86 »
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: 577
Antw:10_KNX.pm Weiterentwicklung
« Antwort #140 am: 02 Juni 2021, 09:21:43 »
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...
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: 2920
  • Anti-Statement befreite Zone ;)
Antw:10_KNX.pm Weiterentwicklung
« Antwort #141 am: 02 Juni 2021, 09:40:13 »
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 :)
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 tom1607

  • New Member
  • *
  • Beiträge: 8
Antw:10_KNX.pm Weiterentwicklung
« Antwort #142 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.

grüße
Thomas

Offline Hauswart

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 859
Antw:10_KNX.pm Weiterentwicklung
« Antwort #143 am: 18 Juni 2021, 11:09:52 »
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:
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
1. Installation:
KNX, Tasmota (KNX), Sonos, Unifi

2. Installation:
HM-CFG-USB, Unifi (, SIGNALduino 868, MySensors, SIGNALduino 433)

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 577
Antw:10_KNX.pm Weiterentwicklung
« Antwort #144 am: 08 Juli 2021, 09:35:33 »
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
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 Kohle77

  • Full Member
  • ***
  • Beiträge: 107
Antw:10_KNX.pm Weiterentwicklung
« Antwort #145 am: 13 Juli 2021, 10:00:46 »
Hallo,
wenn ich in der FHEM Zeile:
version 10_KNX.* absetze bekomme ich:
Zitat
File      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 foundGruß
Christian

Offline erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 577
Antw:10_KNX.pm Weiterentwicklung
« Antwort #146 am: 19 Juli 2021, 17:29:23 »
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
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 erwin

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 577
Antw:10_KNX.pm Weiterentwicklung
« Antwort #147 am: 17 August 2021, 10:54:14 »
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
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 GammaTwin

  • Full Member
  • ***
  • Beiträge: 135
Antw:10_KNX.pm Weiterentwicklung
« Antwort #148 am: 17 August 2021, 12:32:37 »
Test läuft :)

Offline Hauswart

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 859
Antw:10_KNX.pm Weiterentwicklung
« Antwort #149 am: 19 August 2021, 11:28:04 »
Die Version läuft bei mir derzeit unauffällig im Produktivbetrieb.
1. Installation:
KNX, Tasmota (KNX), Sonos, Unifi

2. Installation:
HM-CFG-USB, Unifi (, SIGNALduino 868, MySensors, SIGNALduino 433)