Modul 10_KNX.pm - support

Begonnen von erwin, 23 August 2021, 08:59:59

Vorheriges Thema - Nächstes Thema

erwin

#105
Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
Bitte die geänderte cmd-ref zum Thema KNX_scan beachten!
l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

thorte

Hallo Erwin,

hast Du mit dem letzten Update was am Parsing der DEF geändert?

Meine bishigen DEF sind alle nach dem Schema
1/2/15:dpt1.001:schalten_set:nosuffix
angelegt. [set|get|listenonly] nutzte ich nur, wenn ich kein "get" oder "listenonly" möchte. Laut Hilfe ist die Angabe weiterhin optional, allerdings meckert das Modul
KNX_define2 (KNX_0102015): invalid option for group-number 1. Use one of: get|set|listenonly
interpretiert den Parameter also nicht als optional.

Beabsichtigt?
Gruß Thorsten


erwin

Hi Thorsten!
Zitathast Du mit dem letzten Update was am Parsing der DEF geändert?
Ja hab ich, ....  :(
Problem ist, dass in deinem gadNamen "set" vorkommt!
Das ist aber definitiv erlaubt !
Fehler ist ein einzelnes '^' in einem regex.....
muss noch testen, fix ist morgen im SVN! - sorry
l.g. erwin

PS: falls du sofort testen willst: - ändere die Zeile 553 auf:
$gadOption   = pop(@gadArgs) if (@gadArgs && $gadArgs[-1] =~ /^($PAT_GAD_OPTIONS)$/ixms);
und dann natürlich shutdown restart!
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

erwin

Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

erwin

#109
Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!

Bite auch die Umfrage beachten (Top in diesem thread), es geht darum das Attribut "answerReading" zu entfernen, das würde die Komplexität des codes deutlich reduzieren. Ersatz für die Funktionlität ist gegeben, siehe cmd-ref. Die Umstellung könnte in den meisten Fällen vollkommen automatisch passieren, beim nächsten FHEM start nach dem update.
Wie findet man heraus, ob / in welchem device "answerReading" verwendet wird:
list TYPE=KNX a:answerReading
l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

erwin

Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

Beko136

#111
Hallo,

mit dem letzten Update des Moduls 10_KNX.pm hat in meiner Installation das Anfahren der Rolläden auf eine bestimmte Position aufgehört zu funktionieren. Nach dem Update erscheint eine Fehlermeldung, welche ggf. auf ein ungültiges Datenformat schließen lässt - der genaue Wortlaut ist "2OG_KI_RO_Fenster set invalid value= 65%".
Im FHEM-Log finde ich folgende Zeile:
2OG_KI_RO_Fenster [KNX_checkAndClean 1305]: gadName= g4 value= 65% does not match allowed values
Nach etwas Recherche habe ich dann das Update rückgängig gemacht, 10_KNX.pm aus künftigen Updates exkludiert, alle anderen Updates installiert und dann hat wieder alles wie bisher funktioniert. Damit scheint recht eindeutig das KNX-Modul die Ursache zu sein, nehme ich an.

Ein Auszug aus meiner Rolle-Objekt-Definition in FHEM:
define 2OG_KI_RO_Fenster KNX 7/3/35:dpt5.001 7/3/31:dpt1.001 7/3/32:dpt1.001 7/3/33:dpt5.001
attr 2OG_KI_RO_Fenster IODev KNX
attr 2OG_KI_RO_Fenster eventMap /on g3:Stop/off g2:Auf/on g2:Ab/value 40% g4:Pos1/value 60% g4:Pos2
attr 2OG_KI_RO_Fenster webCmd Ab:Stop:Auf:Pos1:Pos2

Ist jemandem hierzu etwas bekannt? Lassen sich die beschriebenen Symptome den Update-Modifikationen im Modul 10_KNX.pm zuordnen? Habe ich in meiner FHEM-Definition einen Fehler/eine Inkompatibilität, welche bisher "geduldet", nun aber zu Problemen führt? Die DPT habe ich geprüft, diese sind in Ordnung.

Ich würde mich freuen über den einen oder anderen Hinweis,

danke und sG

erwin

Hi Beko136
Bin dzt. auf Urlaub, bitte um Geduld bis nächste Woche
L.g. Erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

erwin

Hi Beko136,
danke für die ausführliche Problembeschreibung, war sehr hilfreich.
ZitatLassen sich die beschriebenen Symptome den Update-Modifikationen im Modul 10_KNX.pm zuordnen? Habe ich in meiner FHEM-Definition einen Fehler/eine Inkompatibilität, welche bisher "geduldet", nun aber zu Problemen führt?
Ja, wird wohl an diesem update liegen, habe ich aber nicht gegengeprüft.
Das aktuelle Problem liegt an der definition deiner eventmap:
attr 2OG_KI_RO_Fenster eventMap /on g3:Stop/off g2:Auf/on g2:Ab/value 40% g4:Pos1/value 60% g4:Pos2
.. eine Umstellung auf die "neue" syntax (...ist auch bereits 5+ Jahre alt...), löst das Problem!
attr 2OG_KI_RO_Fenster eventMap /g3 on:Stop/g2 off:Auf/g2 on:Ab/g4 40:Pos1/g4 60:Pos2Beachte: keine Einheit im set Kommando!
... und möglicherweise kommt so ein set-cmd auch in if,doif,at... definitionen vor.
PS: ein "set device value xx" cmd war zwar im EIB Modul unterstützt und wurde auch ins KNX-modul übernommen,
es gibt aber kein einziges Beispiel in der cmd-ref und im KNX-Wiki dazu!
Auch hier dokumentiert: Migration EIB-KNX
l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

erwin

Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
Nachden einige funktionelle Änderungen sind...
1) die Attribute readonly,listenonly,slider (deprecated seit 2018) sind nun endgültig entfernt.
2) Spezifizieren von IO-Device in der Definition ist nun endgültig ein Fehler - bisher wurde ignoriert mit error-Msg.
3) Attribut answerreading (war deprecated) wird nun während FHEM-start automatisch auf Attr. putCmd umgestellt. Ein manuelle save ist notwendig! Die diesbez. Umfrage wurde nicht besonders häufig genutzt...
4) Neu: Fehlermeldung, falls ein ungültiges "set <device> on-xxx-yyy" (z.b. ...on-till) cmd versucht wird. Bisher wurde entweder on od. off gesendet, aber KEIN Timer gestartet!
5) etliche code optimierungen und cmd-ref anpassungen.

l.g. erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

erwin

Hi KNX Community!
KNX_scan cmd:
Bin gerade auf ein Problem gestoßen mit dem cmd, und zwar:
Falls mehr als 100 "get xx yy" (mit je 0.2 Sekunden Verzögerung) losgelassen werden, kann mein Weinzeirl IP731 das offensichtlich nicht mehr verarbeiten und reagiert mit Timeouts....bis zu connection lost.
Bis zu 40 get requests gehen problemlos.
Ich bin dabei, einen fix zu entwickeln, in der Zwischenzeit würde mich interessieren, ob noch jemand das Problem hat - mit welchem GW und mit wievielen "get"?
Temporäre Abhilfe: nicht alle "get" mit einem cmd losschicken, sondern z.b. nach FHEM-Raum aufteilen:
KNX_scan room=Gartenl.g.erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

erwin

Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
Die Funktion KNXscan ist jetzt im KNXIO-Modul. - Begründung: funktioniert sowieso nicht mit TUL/KNXTUL Modulen.
Das Problem mit dem KNX_scan cmd wurde gefixt.
Details in der cmdref bzw. im KNXIO-thread!
l.g.erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

jw9

Zitat von: erwin am 15 Juni 2023, 11:05:13Die Funktion KNXscan ist jetzt im KNXIO-Modul. - Begründung: funktioniert sowieso nicht mit TUL/KNXTUL Modulen.
Doch! Es hatte funktioniert! bis zu dem "fix"...

ZitatDas Problem mit dem KNX_scan cmd wurde gefixt.
Details in der cmdref bzw. im KNXIO-thread!
Welches Problem war das? Welchen Thread genau meinst Du?

erwin

ZitatDoch! Es hatte funktioniert! bis zu dem "fix"...
hat es nicht, und das hast du gefunden, danke dafür!
https://forum.fhem.de/index.php?topic=133667.0
... war übrigens dein Thread!

ZitatWelches Problem war das? Welchen Thread genau meinst Du?
siehe Beitrag #115 in diesem Thread...
l.g erwin
FHEM aktuell auf RaspberryPI Mdl 1-4
Maintainer: 00_KNXIO.pm 10_KNX.pm
User: CUNO2 (868 SLOWRF) - HMS100xx, FS20, FHT, 1-Wire  - 2401(iButton), 18x20, 2406, 2413 (AVR), 2450,..,MQTT2, KNX, SONOFF, mySENSORS,....
Hardware:  Busware ROT, Weinzierl IP731, 1-Wire GW,...

jw9

Zitat von: erwin am 28 Juni 2023, 08:49:07
ZitatDoch! Es hatte funktioniert! bis zu dem "fix"...
hat es nicht, und das hast du gefunden, danke dafür!
https://forum.fhem.de/index.php?topic=133667.0
... war übrigens dein Thread!
Ummm...

Wie Du im letzten Absatz von diesem Beitrag selbst schreibst, wäre der korrekte Fix gewesen, in KNXTUL den state:connected zu implementieren. Das hatte ich bei mir (lokal) gemacht. War lediglich eine zusätzliche Zeile: " DoTrigger($name, "CONNECTED") if($reopen);" am Ende von &KNXTUL_OpenDev().

Hat wunderprächtig funktioniert, bis Dein richtiger "fix" kam... :-(