Hi KNX-Community!
Nach einem Jahr Weiterentwicklung des KNX-Moduls (siehe: https://forum.fhem.de/index.php/topic,116737.0.html)
habe ich jetzt in Abstimmung mit dem bisherigen Maintainer (Andi291) die Ownership des Moduls übernommen.
Das Modul ist im SVN verfügbar.
Danke Allen Testern, die Ideen, Vorschläge,Zeit und Geduld zum Testen hier eingebracht haben!
In Summe: Es ist ein heftiger rewrite des Moduls geworden, die wesentlichen Änderungen hier nochmal zusammengefasst:
Device Definition:
Keine Änderungen, aber eine strengere Auslegung der syntax - siehe cmdref. Beim ersten start nach dem update bitte das Log auf Fehlermeldungen checken.
Tip: vor dem shutdown-restart die fhem.cfg file sichern....
Changes:
1) Viele neue/geänderte (sub)-dpts. Als value wird der Text lt. KNX-Standard verwendet. Das kann evtl. Inkompatibilitäten für notifies, doif's,
readingsproxy, ... Definitionen haben, bitte um Check bzw. Anpassung.
z.B. wird ein dpt1.023 jetzt als <b>move_up_down</b> / <b>move_and_step_mode</b> dargestellt, bisher on/off.
Alle Texe mit mehr als einem Wort sind mittels '_' verbunden, sonst funktioniert das FHEM-WEB pulldown nicht!
2) Set CMD Syntax - Im Log gibts Meldungen: "KNX_Set_oldsyntax: you are still using "old syntax",..." - funktioniert trotzdem, nur als Hinweis...
Alte und neue Set-cmd syntax gabs auch im bisherigen Modul, wird auch noch einige Zeit beibehalten, eleganter finde ich die neue syntax...
3) autocreate: Es wird kein neuer Log angelegt und das device wird disabled, bis ein dpt definiert wurde und das disabled attribute gelöscht wird!
Begründung: Das device funktioniert sowieso nicht, bis ein korrekter dpt (manuell) definiert wurde und es ist sinnvoller ein gemeinsames Log
für alle autocreate-KNX-devices zu definieren. Im Normalfall wird das device einen "sinnvollen" Namen bekommen, mittels rename <device>. Siehe Bsp. in der cmdref.
4) Neu: Attribute disable
5) Neu: Attribute KNX_toggle - Details siehe cmdref
6) fix DbLog_split Funktion
7) dpt10 compatibility with widgetoverride :time
8) package FHEM::KNX
9) Anpassung cmdref.
Change History
29.08.: fixed fhem-crash when using KNX_toggle Attribute
04.10.: IODev specification on define is now deprecated (but still working...)
check for valid IO-Module during IODev-Attr definition
changed policy on forbidden GADNames e.g.: onConnect is now allowed
removed "private" eversion
removed unnecessary "return $UNDEF"
removed sub KNX_Notify - not needed!
fixed "old syntax" dpt16 set Forum #122779
modified examples in cmdref - added wiki link
prevent deletion of Attr disable until a valid dpt is defined
changed AnalyzePerlCommand to AnalyzeCommandChain to allow multiple fhem cmds in eval's
code cleanup
15.10 fix dpt1.004, .011, .012, .018 encoding
fix stateregex (KNX_replacebyregex)
fix off-for-timer
add wiki links
new cmd: blink dpt1, dpt1.001
02.11. rework decode- encode- ByDpt (cascading if/else != performance)
fix stateregex once more
removed examples from cmdref -> now avail in wiki
18.11. bugfixes: dpt10 "now", fix dpt19 workingdays, dpt3 encode 0 != 1
### 2022 ###
07.01. feature: KNX_scan utility, support for FHEM2FHEM as IO-Device
18.03. feature: dpt22.101 (receive only), dpt20 deccode fix, UTF8 (units)
07.04. allow 'nosuffix' as only option in define, minor corrections to cmdref
29.04. minor additions to cmdref & some cleanup
19.10. cleanup, replace doubleqoutes in Log3, sprintf,pack,....
add devicename to every Log msg
rework doKNXscan, stateregex
add dpt4, dpt15, added sub-dpts for dpts 3,5,8,9,14; corrected min/max/pattern values in dpts
fix dpt19, dpt11 parsing
unify Log-Msg's
prevent setting deprecated (since 2018!) Attr: readonly,listenonly,slider - with errormsg
prevent setting IODev in define...
.... both will be completly removed with next version
new: Internal "RAWMSG" shows msg from Bus while device is disabled (debugging)
bugfix: allowed group-format corrected: was 0-31/0-15/0-255 -> now: 0-31/0-7/0-255 lt.KNX-spec
30.10. changed package name FHEM::KNX -> KNX
changed svnid format
fix dpt4,dpt16 encode/decode (ascii vs. ISO-8859-1)
fix dpt14.057 unit 'dpt14.057' { cosφ vs. cosφ ) =>need UTF8 in DbLog spec !
new dpt217 - for EBUSD KNX implementation
no default slider in FHEMWEB-set/get for dpt7,8,9,12,13 - use widgetoverride slider !
13.11. cleanup, cmd-ref formatting
05.12. fix dpt217 range/fomatting, cmd-ref links,
remove support for IODev in define
modify disabled logic
27.12. device define starts after init_complete
remove $hash->{DEVNAME}
modify autocreate, get/set logic
changed not user relevant internals to {.XXXX}
changed DbLog_split function
disabled StateFn - no longer needed
### 2023 ###
22.01. simplify DbLogSplitFn
modify KNX_parse - reply msg code
modify KNX_set
add pulldown menu for attr IODev with vaild IO-dev
KNX_scan now avail also from cmd-line - details: see "help KNX" !
28.01. fix define parsing, PBP fixes
NEW: syntax check on attr stateCmd & putCmd
27.03. syntax check bei Attr stateregex
Ankündigung Attr. answerreading als deprecated
Hinweis auf das Modul KNXIO zu migrieren (für user von TUL/KNXTUL)
07.04. Log messgages vereinheitlicht, minimale changes zu argument parsing (checkAndClean)
15.04. fixed unint in define2 [line 543]
fixed allowed range for dpt6.001
add dpt7.002 - 7.004
fixed scaling dpt8.003 .004 .010
25.05. rework define parsing
removed deprecated (since 2018!) Attr's: readonly,listenonly,slider
removed deprecated IODEV from define - errormsg changed!
remove FACTOR & OFFSET keys from %dpttypes where FACTOR = undef/1 or OFFSET= undef/0
correct rounding on dpt5.003 encode
remove trailing zero(s) on reading values
integrate sub checkandclean into encodebydpt
cmd-ref: correct wiki links, W3C conformance...
error-msg on invalid set dpt1 cmd (on-till...)
Attr anwerReading now deprecated - converted to putCmd - autosave will be deactivated during fhem-restart if a answerReading is converted - use save!
15.6. move KNX_scan Function to KNXIO-Module - update both KNXIO and KNX-Module !!!
update cmd-ref
13.7. moved KNX_scan function back to KNX-Module...
28.8. verify allowed oldsyntax cmd's,
deprecate announcement for cmd's: raw,value,string,rgb
improve regex for dpt4, dpt16
add sub-dpts to dpt1,7,8,12,13,14 (new KNX-spec)
change max-limit for dpt9 acc. to new KNX-spec to 670433.28
implementation beta-test dpt251.600, dpt221
new dpt: dptRAW -allow unlimited hex char. w.o. any checking !
do NOT remove leading & trailing zeros on reading values (hex values would be destroyed)
allow more than 14 char on "set dpt16" - truncate during encoding to 1st 14 char
hide set-pulldown for readonly dpts (dpt15,22,217,221)
4.10. allow exponential numbers in set cmd for dpt14, formatting of dpt14 reading values
corr dpt9 min-limit to -671088.64
dpt9, dpt14: deny use of comma as dec-separator...
fix replacebyregex
rework KNX_scan
25.11. replace GP_export function
PBP cleanup -1
correct cmdref links for DbLog attr Fn's
modified limit Log msg
dpttypes optimisation (no variable case regex for numbers)
25.12. code optimisation KNX_scan, doKNX_scan
adapt cmds ref set/get cmd's (new KNXIO feature - send queing)
additional dpts 14.xxx - see cmdref
### 2024 ###
14.01. correct unit for dpt9.026
additional dpts 14.xxx - see cmdref
fix dpt14 min/max values
performance tuning in define
05.03. change dpt1.009 max-value from closed->close
prevent gadName 'state' in define when nosuffix specified
add on-for...|off-for... to forbidden gadNames
Für die user des beta-Moduls: Bitte die GIT Version NICHT MEHR verwenden!
Die GIT version werdet ihr wie folgt los:
update delete https://raw.githubusercontent.com/erw111n/FHEM-KNX/main/controls_KNXevolution.txt
..und zusätzlich im device global attribute exclude_from_update den Eintrag:
fhem.de.*:FHEM/10_KNX.pm löschen.
Fehler/Fragen u. Wünsche zum Modul bitte in diesem (oder neuem) Thread posten, am besten unter Angabe von <list device> und Log (falls sinnvoll).
l.g. erwin
Erstmal vielen lieben Dank, dass du dich um die Fortführung des KNX-Moduls kümmerst!
Deine Version läuft bisher sehr stabil.
Wirst du auch das FHEM/00_KNXTUL.pm-Modul in Zukunft weiterführen? :)
Gruss
Hi Hauswart,
danke für die Blumen.....
mal sehen vieviel Probleme es mit der neue Version gibt...
Re: KNXTUL - ich denke eher an ein neues Modul, (Arbeits-Name: KNXIO), dass TUL u. KNXTUL vereint und evtl. zusätzliche Optionen bietet:
Connection Types:
H Host Mode - connect to a KNX-router with UDP point-point protocol. You do not need a KNXD installation.
M Multicast mode - defaut address:port is 224.0.23.12:3671 connect to KNXD's or KNX-router's multicast-tree.
If you have a KNX-router that supports multicast, you do not need a KNXD installation.
This mode requires the <code>IO::Socket::Multicast</code> perl-module to be installed on yr. system.
On Debian systems this can be achieved by apt-get install libio-socket-multicast-perl
T TCP Mode - uses a TCP-connection to KNXD (default port: 6720). This mode is the successor of the TUL-modul, but does not support direct USB connection to a TPUart-USB Stick.
If you want to use a TPUart-USB Stick, use either the TUL Module, or connect the USB-Stick to KNXD and in turn use modes M,S or T to connect to KNXD.
S Socket mode - communicate via KNXD's UNIX-socket on localhost. default Socket-path: /var/run/knxd
aber bis dahin ist's noch ein weiter Weg, ich muss mir was zu meinen Testoptionen überlegen...
l.g. erwin
Hi KNX-Community!
Das Modul ist ab sofort im SVN und ab morgen per update verfügbar.
ich bin etwas nervös.... ;D
l.g. erwin
Danke,
für die Pflege/Fortführung des Moduls.
Ich bin so froh das FHEM noch immer gepflegt wird und nicht von den vielen neuen Smarthome Systemen verdrängt wurde.
Danke an ALLE DEVS.
Wir sind gerade am bauen und haben vor die Verkabelung mit KNX zu machen aber alles was zu verknüpfen und intelligent sein soll wird über FHEM realisiert.
Off-topic:
Denkt ihr es wäre einmal möglich das FHEM sich selbst in kleinere FHEMS aufteilt, und so Multicore supportet.
Mein aktuelles FHEM wird recht wenig ausgelastet.
Danke
LG
Koal
Servus zusammen,
ist die Definition eines KNX devices nicht etwas _zu_ streng ausgelegt?
Laut cmdref ist z.B. folgendes erlaubt:
define mySwitch KNX 9/2/11:dpt1.001:onoff:set
oder
define myThermostat 8/4/125:dpt9.001:setpoint_heating_comfort:set
das neue Modul meckert, weil im gadNamen weder set noch get noch onoff etc. als PRE-fixe verwendet werden dürfen
define mySwitch KNX 9/2/11:dpt1.001:onoff:set
muß ich also umschreiben zu z.B.
define mySwitch KNX 9/2/11:dpt1.001:K_onoff:set
dann gehts....
ich hab' über 500 derartige definitionen....
oder verstehe ich da die cmdref falsch??
Gruß,
Thomas.
Hi Thomas,
ich hoffe die cmd-ref ist eindeutig:
ZitatThe gadName must not begin with one of the following strings: on, off, on-for-timer, on-until, off-for-timer, off-until, toggle, raw, rgb, string, value, set, get, listenonly, nosuffix.
Auf Deutsch: ... darf nicht beginnen mit ...
Dass Problem ist, dass historisch bedingt die einzelnen parameter positional ausgewertet werden.
beispiel:
define xxx KNX1/1/1:dpt1:nosuffixwürde ich das erlauben, dann würde das ein GAD-Name sein, und nicht das was es sein soll!
Noch schlimmer wird's dann bei den set-cmd's:
set xxx on setzt die ERSTE GAD (g1) auf value on (= gültiges cmd) und gilt sinngemäß auch für (fast) alle anderen Device-Module in FHEM
falls ich aber on als GAD-namen erlauben, dann passiert folgendes:
set xxx on - setzt GAD-namen on auf value undefined!
not easy...
um das zu umgehen, müsste man eine Key->value syntax erfinden, z.b.: Model=dpt1 Alias=on Dir=set Suffix=no ... - und dann wär die kompatibilität komplett zerstört!
l.g erwin
Hallo Erwin,
ich habe noch eine Frage. Es ist zwar nicht anders mit der neuen Version, aber vlt gibt es hier ein Möglichkeit dies zu ändern.
Für Jalousien habe ich mehrere Gruppenadressen in einem Device definiert. Trotzdem wird dann für alle Gruppenadressen ein Device benötigt (also auch 3/3/8, 3/3/9 und 3/3/23). Was ist der Grund dafür, bzw wie kann ich das verhindern?
Internals:
DEF 3/3/10:dpt5.001:position 3/3/8:dpt1:Auf_Ab 3/3/9:dpt1:Stop 3/3/23:dpt5.001:Status_Hoehe
DEVNAME Jalousie_Kinderzimmer_Ost
FIRSTGADNAME position
FUUID 5e9c0868-f33f-e2c0-7caa-783d23bb89d25150
FVERSION 10_KNX.pm:0.248910/2021-08-29
FVERSIONE 04.67 18-08-2021
GETSTRING Status_Hoehe:noArg Auf_Ab:noArg position:noArg Stop:noArg
IODev KNX
KNX_MSGCNT 82
KNX_RAWMSG C01138w0330801
KNX_TIME 2021-09-19 20:06:19
LASTInputDev KNX
MSGCNT 82
NAME Jalousie_Kinderzimmer_Ost
NOTIFYDEV global,Jalousie_Kinderzimmer_Ost
NR 848
NTFY_ORDER 50-Jalousie_Kinderzimmer_Ost
SETSTRING Status_Hoehe:slider,0,1,100 Auf_Ab:off,on position:slider,0,1,100 Stop:off,on
STATE on
TYPE KNX
GADDETAILS:
Auf_Ab:
CODE 03308
GROUP 3/3/8
MODEL dpt1
NO 2
OPTION
RDNAMEGET Auf_Ab-get
RDNAMEPUT Auf_Ab-put
RDNAMESET Auf_Ab-set
SETLIST :off,on
Status_Hoehe:
CODE 03317
GROUP 3/3/23
MODEL dpt5.001
NO 4
OPTION
RDNAMEGET Status_Hoehe-get
RDNAMEPUT Status_Hoehe-put
RDNAMESET Status_Hoehe-set
SETLIST :slider,0,1,100
Stop:
CODE 03309
GROUP 3/3/9
MODEL dpt1
NO 3
OPTION
RDNAMEGET Stop-get
RDNAMEPUT Stop-put
RDNAMESET Stop-set
SETLIST :off,on
position:
CODE 0330a
GROUP 3/3/10
MODEL dpt5.001
NO 1
OPTION
RDNAMEGET position-get
RDNAMEPUT position-put
RDNAMESET position-set
SETLIST :slider,0,1,100
GADTABLE:
03308 Auf_Ab
03309 Stop
0330a position
03317 Status_Hoehe
READINGS:
2021-09-10 22:10:11 ASC_Enable on
2021-09-11 23:07:27 ASC_ShadingMessage <html> WARN: global shading active but ASC_Shading_Mode attribut is not set or off </html>
2021-09-10 22:10:11 ASC_ShuttersLastDrive manual
2021-09-19 19:31:15 ASC_Time_DriveDown 20.09.2021 - 19:31
2021-09-19 19:31:15 ASC_Time_DriveUp 20.09.2021 - 08:00
2021-09-19 20:06:19 Auf_Ab-get on
2021-09-10 22:10:11 Auf_Ab-set off
2021-09-10 22:10:11 IODev KNX
2021-09-19 20:06:19 Position 100 %
2021-09-19 19:46:07 Status_Hoehe-get 100 %
2021-09-18 06:43:21 Stop-get on
2021-09-10 22:10:11 Stop-set on
2021-09-10 22:10:11 associatedWith ASC
2021-09-10 22:10:11 getG2 off
2021-09-10 22:10:11 getG3 on
2021-09-10 22:10:11 getG4 0 %
2021-09-19 20:06:19 last-sender 1.1.56
2021-09-10 22:10:11 position-set 100 %
2021-09-10 22:10:11 setG2 off
2021-09-10 22:10:11 setG3 on
2021-09-19 20:06:19 state on
Attributes:
ASC 1
ASC_AutoAstroModeMorning CIVIL
ASC_BrightnessSensor KNX_0000005:Helligkeit
ASC_Closed_Pos 100
ASC_DriveUpMaxDuration 17
ASC_Mode_Down off
ASC_Mode_Up off
ASC_Open_Pos 0
ASC_Pos_Reading position
ASC_PrivacyDown_Pos 50
ASC_RainProtection off
ASC_Shading_Min_OutsideTemperature 10
ASC_Shading_Mode off
ASC_Shading_Pos 100
ASC_Shading_StateChange_SunnyCloudy 20000:15000
ASC_Shading_WaitingPeriod 600
ASC_Sleep_Pos 100
ASC_TempSensor KNX_0004000:WERT
ASC_Time_Up_Early 08:00
ASC_Up astro
IODev KNX
alias Jalousie_Kinderzimmer_Ost
andFHEM_alias Jalousie_KiZi_Ost
cmdIcon Auf:rc_DOWN Ab:rc_UP Stop:rc_RED
devStateIcon { my $wert = 10* int(0.1*ReadingsNum($name,'state',0)+0.5);; ".*:fts_shutter_1w_".$wert.":noFhemwebLink"}
event-on-change-reading .*
eventMap /on g3:Stop/off g2:Auf/on g2:Ab/off
group Jalousien_OG
icon fts_shutter_30
room Jalousien,OG->Kinderzimmer
userReadings Position { ReadingsVal("Jalousie_Kinderzimmer_Ost","Status_Hoehe-get",0) }
userattr ASC_Adv:on,off ASC_Antifreeze:off,soft,hard,am,pm ASC_Antifreeze_Pos:5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100 ASC_AutoAstroModeEvening:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeEveningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_AutoAstroModeMorning:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeMorningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_BlockingTime_afterManual ASC_BlockingTime_beforDayOpen ASC_BlockingTime_beforNightClose ASC_BrightnessSensor ASC_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_ComfortOpen_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Down:time,astro,brightness,roommate ASC_DriveUpMaxDuration ASC_Drive_Delay ASC_Drive_DelayStart ASC_ExternalTrigger ASC_GuestRoom:on,off ASC_LockOut:soft,hard,off ASC_LockOut_Cmd:inhibit,blocked,protection ASC_Mode_Down:absent,always,off,home ASC_Mode_Up:absent,always,off,home ASC_Open_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Partymode:on,off ASC_Pos_Reading ASC_PrivacyDownValue_beforeNightClose ASC_PrivacyDown_Pos ASC_PrivacyUpValue_beforeDayOpen ASC_PrivacyUp_Pos ASC_RainProtection:on,off ASC_Roommate_Device ASC_Roommate_Reading ASC_Self_Defense_AbsentDelay ASC_Self_Defense_Mode:absent,gone,off ASC_Shading_BetweenTheTime ASC_Shading_InOutAzimuth ASC_Shading_MinMax_Elevation ASC_Shading_Min_OutsideTemperature ASC_Shading_Mode:absent,always,off,home ASC_Shading_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Shading_StateChange_SunnyCloudy ASC_Shading_WaitingPeriod ASC_Shutter_IdleDetection ASC_ShuttersPlace:window,terrace,awning ASC_SlatPosCmd_SlatDevice ASC_Sleep_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_TempSensor ASC_Time_Down_Early ASC_Time_Down_Late ASC_Time_Up_Early ASC_Time_Up_Late ASC_Time_Up_WE_Holiday ASC_Up:time,astro,brightness,roommate ASC_Ventilate_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Ventilate_Window_Open:on,off ASC_WiggleValue ASC_WindParameters ASC_WindProtection:on,off ASC_WindowRec ASC_WindowRec_PosAfterDayClosed:open,lastManual ASC_WindowRec_subType:twostate,threestate room_map structexclude
webCmd Ab:Stop:Auf
lg,
Matthias
Hi Matthias,
ZitatTrotzdem wird dann für alle Gruppenadressen ein Device benötigt
..Du meinst zusätzliche FHEM-devices ? - wozu? - ich verstehe die Frage nicht .
Ein Beispiel von mir - für einen Rolladen:
Internals:
DEF 5/1/53:dpt1.008:aufab:set:nosuffix
5/1/55:dpt1.010:stop:set:nosuffix
5/1/57:dpt1:moving:listenonly:nosuffix
5/1/58:dpt5.001:position:set:nosuffix
5/1/60:dpt5.001:posstatus:get:nosuffix
5/1/72:dpt1:block:set:nosuffix
5/1/65:dpt1:uppos:listenonly:nosuffix
5/1/66:dpt1:dnpos:listenonly:nosuffix
DEVNAME Jal_Kueche
FIRSTGADNAME aufab
FUUID 5c7ceaf9-f33f-5c4d-a2bd-3f2aea40d3a26d86
FVERSIONE 04.67 18-08-2021
GETSTRING posstatus:noArg
IODev myKNXD
LASTInputDev myKNXD
MSGCNT 360
NAME Jal_Kueche
NOTIFYDEV global,Jal_Kueche
NR 31
NTFY_ORDER 50-Jal_Kueche
SETSTRING position:slider,0,1,100 stop:stop,start block:off,on aufab:up,down
STATE 0
TYPE KNX
myKNXD_MSGCNT 360
myKNXD_RAWMSG C00151w0513900
myKNXD_TIME 2021-09-20 06:45:16
GADDETAILS:
.......
READINGS:
2021-08-27 12:13:22 IODev myKNXD
2021-09-20 06:44:47 aufab up
2021-09-20 06:44:48 dnpos off
2021-09-20 06:45:16 last-sender 0.1.81
2021-09-20 06:45:16 moving off
2021-09-20 06:45:16 position 0 %
2021-09-20 06:45:16 posstatus 0 %
2021-09-20 06:45:16 state 0
2021-09-15 20:54:01 stop stop
2021-09-20 06:45:13 uppos on
helper:
......
Attributes:
DbLogExclude last-sender,.*:1
IODev myKNXD
cmdIcon Auf:black_up Ab:black_down Stop:remotecontrol/black_btn_RED
comment GA's: aufab,stop,movestatus,posstatus,Setposition,block,uppos,dnpos
devStateIcon {Jal_devStateIcon()}
eventMap { usr=>{"Stop"=>"stop stop","Auf"=>"aufab up","Ab"=>"aufab down"} }
fp_FP_EG 82,1037,5,Jal_Kueche,
group Jalousie
room Jalousie
stateCmd {Jal_stateCmd($name,$gadName,$state)}
webCmd Auf:Ab:position
widgetOverride position:slider,0,5,100
Das GAD moving schickt mein MDT-Aktor, solang der Rolladen sich bewegt (Parameter ETS)! das ist wichtig, sonst funktioniert das nicht...
Die GAD's: block,uppos,dnpos sind optional.
was es dazu noch braucht, sind 2 subs (in 99_myUtils.pm) damit:
1) der state jeweils vernüftig gesetzt wird,
2) das DevstateIcon die Position des Rollladen anzeigt und der stop cmd durch anklicken der Icons realisiert wird.
3) noch ein notify, dass das posstatus-reading (= Rückmeldung RollladenPosition) in das position-reading kopiert, damit der slider jederzeit richtig steht!
bei Interesse schick ich die die entsprechenden subs / notify...
Ich hatte schon einmal überlegt, das als Beispiel in die cmd-ref aufzunehmen, aber es gab Kritik über "überbordende cmd-ref's".....
l.g.erwin
Hallo Erwin,
danke. Ich muss mir Deine Definition einer Jalousie genauer ansehen ob hier die Lösung liegt.
Ich bekommen bei meiner Defintion dann folgende Einträge im Log:
KNX_Parse (wp): KNX_0303008, READINGNAME: getG1, message C01138w0330800 could not be decoded
sprich, es wird KNX_0303008 (3/3/8) verlangt, obwohl in der Jalousie definiert.
lg,
Matthias
das kann nur passieren, wenn du in deiner config ein device:
KNX_0303008
definiert hast, vermutlich ohne :dptx.... und nicht disabled!
... weil sonst würde der device-name nicht in der err-msg vorkommen!
Einfach die def löschen!
l.g.erwin
Hallo Erwin,
also ich hatte in der Vergangenheit die Devices ausdefiniert, die vom Modul automatisch angelegt wurden.
Ich habe kürzlich etwas aufgeäumt und bei einigen Devices mehrere Gruppenadressen kombiniert und dann eine Vielzahl von Devices gelöscht.
KNX_0303008 war eines der gelöschten Devices. Ab dem 8.9. sehe ich die Logeinträge, obwohl diese Gruppenadresse in der Jalousie verwendet wird. Siehe List im letzten Posting.
pi@raspberrypi4:/opt/fhem/log $ less fhem-2021-08.log | grep KNX_0303008
pi@raspberrypi4:/opt/fhem/log $ less fhem-2021-09.log | grep KNX_0303008
2021.09.08 20:28:58 2: KNX_Parse (wp): KNX_0303008, READINGNAME: getG1, message C01138w0330801 could not be decoded
2021.09.09 07:10:38 2: KNX_Parse (wp): KNX_0303008, READINGNAME: getG1, message C01138w0330800 could not be decoded
2021.09.09 10:54:46 2: KNX_Parse (wp): KNX_0303008, READINGNAME: getG1, message C01138w0330801 could not be decoded
2021.09.09 13:21:51 2: KNX_Parse (wp): KNX_0303008, READINGNAME: getG1, message C01138w0330800 could not be decoded
Ich weiss, dass ich dptx hinzufügen müßte, dachte aber dass ich dieses Device nicht brauche. Liegt das an meiner Definition der Jalousie?
lg,
Matthias
ok, wenn es das device wirklich nicht mehr gibt (list KNX_....),
Mach mal einen fhem restart - Evtl. sind da "versteckte config-Leichen" noch im system.
PS: wenn es das device JETZT noch geben sollte - müsste diese msg jedesmal kommen, wenn du die Jal bedienst.... - einfach löschen!
l.g. erwin
Danke. Nach dem nochmaligen Löschen und Restart war das Problem dann weg.
lg,
Matthias
hello
I have an issue with the new version, I have a Gad which was called "offset-control"
It is now marked as forbidden, but is not part of the forbidden words. I guess it is because it begins with "off" ?
Is it a bug or do I really need to update all my thermostats ?
regards
Sorry,
i'm afraid you have to change yr. Gad-Names - parsing user input is almost as complicated as writing the logic!
See my reply from 11 September 2021, 22:17:20 in this thread.
cmd-ref:
ZitatThe gadName must not begin with one of the following strings: on, off, on-for-timer, on-until, off-for-timer, off-until, toggle, raw, rgb, string, value, set, get, listenonly, nosuffix.
regards Erwin
PS: if you want to try an experiment, you can edit 10_KNX.pm file and change line 423:
# elsif ($gadArgs[0] =~ m/^$PAT_GAD_NONAME.*/ix) { # check for forbidden names
elsif ($gadArgs[0] =~ m/^$PAT_GAD_NONAME$/ix) {
Pls. give feedback of any side effects... thanks
Hallo Erwin,
danke für Deinen Support bzgl der Jalousie. Nach dem Anpassen scheint soweit das Logfile recht sauber zu sein.
Ich habe noch ein paar Einträge, bei denen ich nicht weiss von welchem Device diese kommen.
2021.10.01 20:59:19 3: KNX_checkAndClean: value= g3 on was casted to 3
2021.10.01 21:00:08 3: KNX_checkAndClean: value= g2 on was casted to 2
Wäre es hier möglich bei KNX_checkAndClean den Devicenamen auch anzugeben?
lg,
Matthias
Hi Matthias,
ZitatWäre es hier möglich bei KNX_checkAndClean den Devicenamen auch anzugeben?
... hab's eingebaut, bin am finalen testen der nächsten Version, bitte um ein paar Tage noch Geduld!
l.g. erwin
Hi KNX Community,
eine neue Version ist am SVN, change history: siehe erster Beitrag!
l.g. erwin
Vielen Dank. Ist schon eingespielt.
lg,
Matthias
eingespielt :)
Mal schauen :)
Hallo Erwin,
Danke erst einmal für deinen Einsatz das Modul weiter zu pflegen!
Ich habe sehr viele KNX Geräte und bisher läuft die Umstellung ohne Probleme.
Nur im Log tauchen immer die Old Syntax Meldungen bei meinen Rollos auf und ich sehe keine Abweichung zur cmdref.
Hier mal ein Rollo Define:
Internals:
DEF 8/1/1:dpt5.001 2/2/0:dpt1.008 2/2/1:dpt1.008 8/2/1:dpt5.001
DEVNAME Arbeit.Rollo
FIRSTGADNAME g1
FUUID 5c7ab74f-f33f-d8f3-b201-c99ef7a724c3b9a1
GETSTRING g1:noArg g2:noArg g3:noArg g4:noArg
IODev KNX
KNX_MSGCNT 3
KNX_RAWMSG C01107w0820100
KNX_TIME 2021-10-06 10:24:55
LASTInputDev KNX
MSGCNT 3
NAME Arbeit.Rollo
NR 638
SETSTRING g1:slider,0,1,100 g2:up,down g3:up,down g4:slider,0,1,100
STATE 0 %
TYPE KNX
model dpt5
GADDETAILS:
g1:
CODE 08101
GROUP 8/1/1
MODEL dpt5.001
NO 1
OPTION
RDNAMEGET getG1
RDNAMEPUT putG1
RDNAMESET setG1
SETLIST :slider,0,1,100
g2:
CODE 02200
GROUP 2/2/0
MODEL dpt1.008
NO 2
OPTION
RDNAMEGET getG2
RDNAMEPUT putG2
RDNAMESET setG2
SETLIST :up,down
g3:
CODE 02201
GROUP 2/2/1
MODEL dpt1.008
NO 3
OPTION
RDNAMEGET getG3
RDNAMEPUT putG3
RDNAMESET setG3
SETLIST :up,down
g4:
CODE 08201
GROUP 8/2/1
MODEL dpt5.001
NO 4
OPTION
RDNAMEGET getG4
RDNAMEPUT putG4
RDNAMESET setG4
SETLIST :slider,0,1,100
GADTABLE:
02200 g2
02201 g3
08101 g1
08201 g4
READINGS:
2021-10-06 10:01:55 BeschattungsDevice Beschatt_Buero
2021-10-06 10:01:55 IODev KNX
2021-10-06 10:01:55 getG1 on
2021-10-06 10:01:55 getG2 down
2021-10-06 10:01:55 getG3 up
2021-10-06 10:24:55 getG4 0 %
2021-10-06 10:24:55 last-sender 1.1.7
2021-10-06 10:01:55 setG1 35 %
2021-10-06 10:24:47 setG2 off
2021-10-06 10:21:56 setG3 on
2021-10-06 10:24:55 state 0 %
Attributes:
IODev KNX
alias Rollladen
devStateIcon {rolloDevStateIcon($name);}
eventMap /on g2:Ab/on g3:Stop/off g2:Auf/value 35 g1:Halb
genericDeviceType blind
group Arbeitszimmer
room EG
sortby 400
webCmd Ab:Stop:Auf:Halb
Sobald ich den Rollo bewege, kommt eine neue Old Syntax Warnung ins Log.
Hast Du einen Tipp, was ich in der Definition falsch mache?
Danke & Grüße,
Roger
Hi Roger,
Danke fürs Feedback,
deine def ist absout korrekt, wo das Problem ist: - bei einem Set-cmd - der gemacht wird sobald du auf "AUF/AB/STOP/HALB" drückst!
Ändere mal die eventMap auf:
eventMap /g2 on:Ab/g3 on:Stop/g2 off:Auf/g1 35:Halb/
...es könnte auch noch ein notify/doif,.. sein wo die alte syntax vorkommt!
Schau die bitte auch die neue wiki Seite: https://wiki.fhem.de/wiki/KNX_Device_Definition_-_Beispiele (https://wiki.fhem.de/wiki/KNX_Device_Definition_-_Beispiele) an, z.B. Slider mit Rückmeldung - oder Jalousie/Rolladen, da wird zwar mit gadNamen (statt Gx) definiert, ist aber sinngemäß das gleiche.
l.g. erwin
Super Erwin!
Dein eventMap Vorschlag hat es gelöst.
Danke :-)
Roger
Oh, der Wiki Eintrag ist nice. Insbesondere die Beispiel zu den Rollos, da werde ich die Tage wohl mal umbauen müssen bei mir. Das gefällt mir gut, was du da gebaut hast. Danke
Hi Amenophis86,
Danke für die Blumen...
Übrigens: Es sind ALLE eingeladen, weitere (funktionierende) Beispiele in den wiki-Beitrag zu stellen. Wer keinen wiki Zugang hat, kann mir seine Vorschläge gern per pm od. mail schicken!
Ich hab das wiki bisher nicht besonders gemocht, aber mit dem VisualEditor komme ich zurecht ;D
Der Beitrag soll einmal der Ankerpunkt fürs KNX-Modul werden, daher könnte sich der namen/link noch ändern!
Mittelfristig ist geplant, die Beispiele aus der cmd-ref zu entfernen und durch einen Link aufs wiki zu ersetzen. - Es gab schon Kritik wg. übergroßer cmd-ref.
l.g. erwin
Hallo Erwin,
bei mir funktioniert seit dem letzten KNX Modul Update die Option "on-for-timer" nicht mehr. Wenn der Timer abgelaufen ist, dann passiert nichts. Es gibt aber keine Erroreinträge oder sonstige Hinweise im Logfile.
Hast Du etwas geändert in der Richtung?
lg
Matthias
Hi Matthias,
bitte um list <device>
und setzte das device auf loglevel5 und mach dann ein set <device> on-for-timer 2
.. und poste auch den log-Ausschnitt
l.g.erwin
Hi,
also hier der Log mit level 5:
2021.10.07 20:56:18 5: KNX_Set -enter: KNX_0101000, g1, on-for-timer, 10
2021.10.07 20:56:18 5: KNX_Set: set KNX_0101000: desired target is gad: steuern, command: g1 on-for-timer 10, args: on-for-timer 10
2021.10.07 20:56:18 5: KNX_checkAndClean -enter: value= on, gadName= steuern
2021.10.07 20:56:18 5: KNX_checkAndClean -exit: value= on, gadName= steuern, model= dpt1, pattern= (?^ix:((on)|(off)|(0?1)|(0?0)))
2021.10.07 20:56:18 5: KNX_encodeByDpt: steuern model: dpt1, code: dpt1, value: on
2021.10.07 20:56:18 5: KNX_encodeByDpt -exit: model: dpt1, code: dpt1, value: on, hexval: 01
2021.10.07 20:56:18 4: KNX_Set: KNX_0101000, cmd= g1 on-for-timer 10, value= on, translated= 01
2021.10.07 20:56:18 5: KNX_Set: -exit
2021.10.07 20:56:18 4: KNX_Parse -process: IO-name: KNX, device-name: KNX_0101000, rd-name: status, gadCode: 01103, cmd: w
2021.10.07 20:56:18 5: KNX_decodeByDpt -enter: model: dpt1, code: dpt1, value: 01, length-value: 2
2021.10.07 20:56:18 5: KNX_decodeByDpt -exit: model: dpt1, code: dpt1, value: 01, state: on
2021.10.07 20:56:18 4: KNX_Parse (wp): KNX_0101000, READINGNAME: status-get, VALUE: on, SENDER: 01115
Und das List:
Internals:
DEF 1/1/0:dpt1:steuern 1/1/3:dpt1:status
DEVNAME KNX_0101000
FIRSTGADNAME steuern
FUUID 5c42d929-f33f-e2c0-a993-1f31f6a13dbc55c4
GETSTRING steuern:noArg status:noArg
IODev KNX
KNX_MSGCNT 8
KNX_RAWMSG C01115w0110300
KNX_TIME 2021-10-07 20:57:22
LASTInputDev KNX
MSGCNT 8
NAME KNX_0101000
NR 115
SETSTRING on:noArg off:noArg steuern:off,on status:off,on
STATE off
TYPE KNX
model dpt1
GADDETAILS:
status:
CODE 01103
GROUP 1/1/3
MODEL dpt1
NO 2
OPTION
RDNAMEGET status-get
RDNAMEPUT status-put
RDNAMESET status-set
SETLIST :off,on
steuern:
CODE 01100
GROUP 1/1/0
MODEL dpt1
NO 1
OPTION
RDNAMEGET steuern-get
RDNAMEPUT steuern-put
RDNAMESET steuern-set
SETLIST :off,on
GADTABLE:
01100 steuern
01103 status
READINGS:
2021-10-07 20:31:04 IODev KNX
2021-10-07 20:31:04 getG1 off
2021-10-07 20:57:22 last-sender 1.1.21
2021-10-07 20:31:04 setG1 off
2021-10-07 20:57:22 state off
2021-10-07 20:57:22 status-get off
2021-10-07 20:31:04 steuern-get off
2021-10-07 20:57:21 steuern-set off
Attributes:
IODev KNX
alias Licht Gang Keller
devStateIcon on:on:off off:off:on
event-on-change-reading .*
icon light_downlight
room KG->Keller
userattr room_map structexclude
verbose 5
webCmd on:off
lg,
Matthias
Hi Matthias,
ich habs:
du definerst die 1/1/0:dpt1:steuern
aber das set: set <device> g1 on-for-timer 10
richtig wäre: set <device> steuern on-for-timer 10
woher kommt das set ??
Hi Erwin,
tatsächlich. Eigentlich ist mir das Problem bei anderen Devices aufgefallen die mit g1 definiert sind. Zum Testen habe ich ein Device genommen, dass ich aber von der Couch aus sehen kann. Bei dem war der set Befehl (g1 statt steuern) natürlich falsch.
Ich habe jetzt noch zwei falsche set Befehle in DOIFs entdeckt (ohne g1) und eliminiert.
Was ich aber nicht ganz verstehe ist, warum das Device auf on ging und nur der Parameter "on-for-timer 10" nicht akzeptiert wurde. Der Befehl war g1 auf on zu schalten und warum geht "steuern" auf on? Eine Fehlermeldung sollte kommen und nichts sollte auf on gehen.
Aber ok, wenn alles richig definiert ist, sollte es kein Problem geben.
Danke nochmals für die Hilfe.
lg
Matthias
Hi,
wenn der cmd: on oder off ist, kann ich das eindeutig zuordnen, falls allerdings 2 worte (oder Argumente) im cmd vorkommen,
geht das nicht mehr und ich muß checken, ob das ein valider gadName ist!
Das mit der Fehlermeldung muß ich mir in Ruhe anschauen.
l.g. erwin
Nächste Version ist am SVN (changes: siehe 1ster Beitrag).
Neu ist ein blink cmd für dpt1, dpt1.001 - analog zu SetExtensions
Eine zus. Errormeldung, falls ein ungültiger gadName in einem set verwendet wird.
Alle Beispiele sind jetzt auch im WIKI zu finden, die links zum wiki sind in der cmd-ref!
Die cmdref wird in der nächsten Version KEINE (erweiterten) Beispiele mehr haben!
l.g. erwin
Hallo Erwin,
mir ist eben aufgefallen, dass ich scheinbar ein Problem mit der Funktion StateRegex habe.
Ist die Szene 0 aktiv wird, wie gewünscht, der Text im state übernommen.
Sobald der Wert abweicht, wird der Text nicht angezeigt.
Habe ich irgendetwas übersehen in der CommandRef?
Ich habe für beide Zustände mal das Listing angefügt.
Update auf die aktuelle Version habe ich kurz vorher gemacht.
Viele Grüße
Markus
Szene 0
Internals:
DEF 2/2/15:dpt5:szene:nosuffix
DEVNAME eg_wz_lz_lichtszene
FIRSTGADNAME szene
FUUID 6048e1f9-f33f-adf4-5279-d2d81283722e9e4c
GETSTRING szene:noArg
IODev KNXD
NAME eg_wz_lz_lichtszene
NR 295
SETSTRING szene:slider,0,2,255
STATE Fernsehen
TYPE KNX
model dpt5
GADDETAILS:
szene:
CODE 0220f
GROUP 2/2/15
MODEL dpt5
NO 1
OPTION
RDNAMEGET szene
RDNAMEPUT szene
RDNAMESET szene
SETLIST :slider,0,2,255
GADTABLE:
0220f szene
READINGS:
2021-10-19 20:17:44 IODev KNXD
2021-10-19 21:07:08 last-sender fhem
2021-10-19 21:07:08 state Fernsehen
2021-10-19 21:07:08 szene 0
Attributes:
alias Lichtszene
devStateIcon Fernsehen:scene_livingroom Lesen:scene_storeroom Alles-Aus:general_aus
event-on-change-reading szene,state
eventMap /szene 0:Fernsehen/szene 1:Lesen/szene 2:Alles-Aus/szene 3:Bügeln/
group Licht
room EG->Wohnzimmer
stateRegex /szene:0/Fernsehen/ /szene:1/Lesen/ /szene:2/Alles-Aus/ /szene:3/Bügeln/
webCmd Fernsehen:Lesen:Alles-Aus
widgetOverride szene:slider,0,1,3
Szene 2
Internals:
DEF 2/2/15:dpt5:szene:nosuffix
DEVNAME eg_wz_lz_lichtszene
FIRSTGADNAME szene
FUUID 6048e1f9-f33f-adf4-5279-d2d81283722e9e4c
GETSTRING szene:noArg
IODev KNXD
NAME eg_wz_lz_lichtszene
NR 295
SETSTRING szene:slider,0,2,255
STATE 2
TYPE KNX
model dpt5
GADDETAILS:
szene:
CODE 0220f
GROUP 2/2/15
MODEL dpt5
NO 1
OPTION
RDNAMEGET szene
RDNAMEPUT szene
RDNAMESET szene
SETLIST :slider,0,2,255
GADTABLE:
0220f szene
READINGS:
2021-10-19 20:17:44 IODev KNXD
2021-10-19 21:10:13 last-sender fhem
2021-10-19 21:10:13 state 2
2021-10-19 21:10:13 szene 2
Attributes:
alias Lichtszene
devStateIcon Fernsehen:scene_livingroom Lesen:scene_storeroom Alles-Aus:general_aus
event-on-change-reading szene,state
eventMap /szene 0:Fernsehen/szene 1:Lesen/szene 2:Alles-Aus/szene 3:Bügeln/
group Licht
room EG->Wohnzimmer
stateRegex /szene:0/Fernsehen/ /szene:1/Lesen/ /szene:2/Alles-Aus/ /szene:3/Bügeln/
webCmd Fernsehen:Lesen:Alles-Aus
widgetOverride szene:slider,0,1,3
Hi Markus,
ich hab da einen Logik-Fehler eingebaut ;D
evtl. kannst du, bis zur nächsten Version, das selbst reparieren:
In der sub-routine KNX_replaceByRegex ab zeile 1324:
elsif (($input !~ /$regPair[0]/x) && ($regPair[0] =~ /[:]/x)) {
$retVal = $input;
next; # <- das fehlt !!!
}
Dann natürlich ein reload 10_KNX.pm oder fhem restart!
sorry erwin
Hallo Erwin,
kein Problem. Ich komme aber erst morgen Vormittag dazu es umzusetzen.
Gebe dann kurz eine Rückinfo.
Einen schönen Abend noch
Viele Grüße
Markus
Hallo Erwin,
habe es eben korrigiert und getestet.
Es funktioniert ohne ersichtliche Probleme.
Ich füge nochmal ein list mit bei.
Danke für deine schnelle Reaktion und Lösung!
Internals:
DEF 2/2/15:dpt5:szene:nosuffix
DEVNAME eg_wz_lz_lichtszene
FIRSTGADNAME szene
FUUID 6048e1f9-f33f-adf4-5279-d2d81283722e9e4c
GETSTRING szene:noArg
IODev KNXD
NAME eg_wz_lz_lichtszene
NR 295
SETSTRING szene:slider,0,2,255
STATE Alles-Aus
TYPE KNX
model dpt5
GADDETAILS:
szene:
CODE 0220f
GROUP 2/2/15
MODEL dpt5
NO 1
OPTION
RDNAMEGET szene
RDNAMEPUT szene
RDNAMESET szene
SETLIST :slider,0,2,255
GADTABLE:
0220f szene
READINGS:
2021-10-20 09:13:47 IODev KNXD
2021-10-20 09:18:46 last-sender fhem
2021-10-20 09:18:46 state Alles-Aus
2021-10-20 09:18:46 szene 2
Attributes:
alias Lichtszene
devStateIcon Fernsehen:scene_livingroom Lesen:scene_storeroom Alles-Aus:general_aus
event-on-change-reading szene,state
eventMap /szene 0:Fernsehen/szene 1:Lesen/szene 2:Alles-Aus/szene 3:Bügeln/
group Licht
room EG->Wohnzimmer
stateRegex /szene:0/Fernsehen/ /szene:1/Lesen/ /szene:2/Alles-Aus/ /szene:3/Bügeln/
webCmd Fernsehen:Lesen:Alles-Aus
widgetOverride szene:slider,0,1,3
Hallo,
ich denke das ich hier richtig bin. Ich versuche grade per KNX ein Viessmann Gate 200 in FHEM zu implementieren.
Siehe auch https://forum.fhem.de/index.php/topic,123827.msg1183908/topicseen.html#msg1183908 (https://forum.fhem.de/index.php/topic,123827.msg1183908/topicseen.html#msg1183908)
Denke aber es gibt keinen richtigen dpt wert für die Raw Messages darzustellen.
Ist es vielleicht möglich einen dpt Wert für ein 4 Byte message anzulegen der einzelne readings pro byte hat?
Gruß
Christian
Neue Version ist am SVN,
changes / fixes:
rework decode- encode- ByDpt (cascading if/else != performance)
fix stateregex once more (danke mgg)
removed examples from cmdref -> now avail in wiki (with link from cmd-ref)
l.g. erwin
Hallo Erwin,
bin erst jetzt dazu gekommen, zum dpt19 via ETS mal auf den Bus zu schauen. Ich habe das Problem, dass mein mdt DaliControl IP64 Gateway Datum / Uhrzeit aus dem FHEM nicht annimmt, im Gegensatz zu den mdt Glastastern. Werte aus der ETS werden angenommen. Ich habe dazu heute mal via ETS und via FHEM jeweils den Zeitstring 06.11.2021_05:00:00 gesetzt. Die Raw-Messages ETS (1) und FHEM (2) sind leicht unterschiedlich:
(1) RawData 2B 07 03 01 07 04 02 1D BC BC E0 FF 12 20 00 09 00 80 79 0B 06 C5 00 00 00 00
(2) RawData 2B 07 03 01 05 04 02 29 79 BC E0 00 02 20 00 09 00 80 79 0B 06 C5 00 00 20 00
Die jeweils kompletten Ausgaben auf dem Busmonitor sind:
aus ETS:
Eigenschaft Wert
RawData 2B 07 03 01 07 04 02 1D BC BC E0 FF 12 20 00 09 00 80 79 0B 06 C5 00 00 00 00
MessageCode LBusmonInd
Source 15.15.18
SourceName -
Destination 4/0/0
DestinationName DatumUhrzeit
RepeatedFlag False
Acknowledge Non
RoutingCounter 6
Priority Low
FrameFormat Standard
Service vom Bus
LocalizedType GroupValueWrite
Type APciGroupValueWrite
Security
TPCI T_Data
APCI APciGroupValueWrite
DataPointType 19.001 Datum/Zeit
RawDpValue 79 0B 06 C5 00 00 00 00
aus FHEM:
Eigenschaft Wert
RawData 2B 07 03 01 05 04 02 29 79 BC E0 00 02 20 00 09 00 80 79 0B 06 C5 00 00 20 00
MessageCode LBusmonInd
Source 0.0.2
SourceName -
Destination 4/0/0
DestinationName DatumUhrzeit
RepeatedFlag False
Acknowledge Non
RoutingCounter 6
Priority Low
FrameFormat Standard
Service vom Bus
LocalizedType GroupValueWrite
Type APciGroupValueWrite
Security
TPCI T_Data
APCI APciGroupValueWrite
DataPointType 19.001 Datum/Zeit
RawDpValue 79 0B 06 C5 00 00 20 00
Bei der Eingabe der Uhrzeit in ETS ist mir aufgefallen, dass ein "Day Of Week" benötigt wird. Vielleicht eine Möglichkeit für den Unterschied?
Falls Du weitere Werte brauchst, gerne melden. Zeit ist allerdings meistens Mangelware.
Gruß Thorsten
Komisch,
der einzige Unterschied, der mir im datenpaket auffällt (abgesehen vom header) ist das vorletzte Byte:
FHEM schickt ein hex 20 vs. ETS ein hex 00
Das NWD bit=0 bedeutet lt. doku: WD - bit valid (working day)
FHEM set das auf 1->ungültig , ETS auf 0-> gültig..
allerding setzt die ETS das WD-bit auf 0 - was bedeuten würde "kein Arbeitstag" - ich bin nicht sicher, wie ein Samstag gewertet wird....
Traust du dir zu, die 10_KNX.pm zu patchen?
Falls ja, dann ändere die Zeile 1653 von:
my $status1 = 0x20; # Fault=0, WD = 0, NWD = 1 (WD Field valid), NY = 0, ND = 0, NDOW= 0,NT=0, SUTI = 0
auf
my $status1 = 0x00; # Fault=0, WD = 0, NWD = 1 (WD Field valid), NY = 0, ND = 0, NDOW= 0,NT=0, SUTI = 0
dann natürlich ein reload 10_KNX.pm bzw. fhem restart....
dann schauen wir, was am Sonntag und am Montag passiert....
l.g. erwin
Asche über mein Haupt - hatte einen Dreher in den Gruppenadressen.
Dabei ist mir aufgefallen: Kann es sein, dass in der 10_KNX.pm nach Zeile 1579 ein
$numval = $secs + ($mins << 8) + ($hours << 16);
fehlt? ein set .... now setzt die Uhrzeit aktuell auf 00:00:00
Am dpt19 habe ich wieder auf den 0x20 zurück geändert und beobachte es.
Gruß Thorsten
ZitatKann es sein, dass in der 10_KNX.pm nach Zeile 1579 ein
.. Asche, Asche....
Völlig richtig - ist irgendwie beim Kopieren verlogengegangen....wird in der nächste Version wieder drin sein!
erwin
Ich habe einen KNX-Taster folgendermaßen definiert, welcher bei mir einen KNX-Dim-Schalter im FHEM emuliert:
defmod Zimmer2_Taster_Dimmen KNX 2/4/29:dpt1.001:einaus 2/4/30:dpt3.007:reldim 2/4/31:dpt5.001:absval
attr Zimmer2_Taster_Dimmen IODev tul
attr Zimmer2_Taster_Dimmen event-on-update-reading .*
attr Zimmer2_Taster_Dimmen eventMap {\
usr=>{\
'down'=>'reldim -100',\
'stop'=>'reldim 0',\
'up'=>'reldim 100',\
'^absval-get (\d+)'=>'absval $1'\
},\
fw=>{\
'^absval-get (\d+)'=>'absval-get'\
}\
}
attr Zimmer2_Taster_Dimmen webCmd on:off:down:stop:up:absval-get
attr Zimmer2_Taster_Dimmen widgetOverride absval-get:slider,0,10,100
Ich kann somit auf "up" oder "down" klicken und es wird ein "reldim [-]100" gesendet. Leider funktioniert seit einiger Zeit das Klicken auf "stop" nicht mehr. Hier wird kein "reldim 0" gesendet, sondern aus einem mir unbekannten Grund ein "reldim 1".
Weiß jemand wo der Fehler liegt?
ZitatWeiß jemand wo der Fehler liegt?
JA, fix ist im test.... ;D
und hoffentlich morgen im update....
update: fix ist im SVN, details im 1sten Beitrag!
l.g. erwin
Danke dir! :)
lg
Ich hätte noch eine Idee eines Features, was sicher keine Eile hat aber mir heute in den Sinn kam. Es wäre cool, wenn man bei jedem Device angeben könnte, dass manche Werte des Device nach einem Neustart + eine Zeit X (selbst wählbar) abgerufen werden bzw. auf den Bus gesendet werden. Ich hatte heute länger FHEM auf Grund von Update und Backup ausgeschaltet und einige Zustände haben natürlich nicht gepasst und dabei kam mir die Idee.
Edit:
Und natürlich könnte man das mit Notify / Doif auch selbst umsetzen aber nativ wäre schöner :)
Die Idee find ich gut, ein Status vom KNX-Bus holen...
Ich habe noch keine Idee, wie realisieren, ich werde mal versuchen, eine Liste zu erstellen, mit allen GAD'S die das (theoretisch) unterstützen.
Das sind mal alle, die "get" in der def haben (sicher),... und auch alle, die kein "set" oder "listenonly" (nicht so sicher) haben...
Auf dieser Basis könnte man so was ähnliches wie ein notify machen, die mittels regex oder Attribut vom User die gewünschten devices weiter selektiert und das get ausführt....
Auslösen das Ganze dann - entweder ein paar Sekunden nach FHEM-start, oder per User command...
Ist das in etwa die Richtung, in die du gedacht hast ?
l.g. erwin
Richtig, get und listenonly wären auch meine Favoriten.
Allerdings würde ich nicht alles auf einmal abfragen. Ich hatte zum Beispiel dran gedacht zwei Attribute pro Device. Attr1 = Die Zeit in Sekunden nach dem Start, wann der Status abgefragt werden soll
Attr2 = für welche GA es gilt, wenn zB mehr als eine GA pro Device definiert sind.
Man könnte die beiden auch zusammen fassen in einem und logisch in der Definition des Attr trennen.
Vorteil wäre, dass ich nicht direkt alles Abfrage und vielleicht den Bus überlaste. Es würde quasi pro Device ein internerTimer gestartet, der nach Ablauf die hinterlegte GA abfragt.
Grüße,
ich habe mir dazu folgendes DOIF gebaut. Wichtiger Punkt war, dass ich die Telegramme pro Sekunde begrenzt habe. Sonst hat der Bus "busy" gemeldet.
Ein Voraussetzung für dieses DOIF ist, dass meine Devices alle mit nosuffix versehen sind.
Ich frage auch reine set-GAs und listenonly-GAs nicht ab.
Als Ergebnis bekommt man noch die Anzahl aller GAs und set, set/get, get, listenonly und vergessene nosuffix.
defmod di_KNX_Status_Aktualisierung DOIF ([$SELF:KNX_Aktualisierung] eq "on" and [?$SELF:KNX_Aktualisierung_Zustand] ne "WIP") {\
fhem("set $SELF KNX_Aktualisierung_Zustand WIP");;\
my @aKNXDevice=devspec2array("TYPE=KNX");;\
my $iDevGesamt=0;;\
my $iSleep=0;;\
my $iAnzGAget=0;;\
my $iAnzGAset=0;;\
my $iAnzGAlistenonly=0;;\
my $iAnzGAsetget=0;;\
my $iNosuffix=0;;\
my $TelegrammeProSek=5;;\
foreach my $KNXDevice (@aKNXDevice) {\
my $KNXDev=InternalVal($KNXDevice,'DEF','NIX');;\
my @aKNXAdress=split(/ /,$KNXDev);;\
my $iDev=0;;\
foreach my $KNXAdress (@aKNXAdress) {\
$iDev++;;\
$iDevGesamt++;;\
if ($KNXAdress !~ m/(\:set\:nosuffix|\:listenonly\:nosuffix)$/) {\
fhem("sleep ".int($iSleep / $TelegrammeProSek).";; get $KNXDevice g$iDev",1);;\
$iSleep++;;\
fhem("sleep ".int($iSleep / $TelegrammeProSek).";; set $SELF AnzAbfrageIst $iSleep",1);;\
if ($KNXAdress =~ m/(\:get\:nosuffix)$/) {\
$iAnzGAget++;;\
} elsif ($KNXAdress !~ m/(\:nosuffix)$/) {\
$iNosuffix++;;\
} else { $iAnzGAsetget++;; };;\
};;\
if ($KNXAdress =~ m/(\:set\:nosuffix)$/) { $iAnzGAset++;; };;\
if ($KNXAdress =~ m/(\:listenonly\:nosuffix)$/) { $iAnzGAlistenonly++;; };;\
};;\
};;\
fhem("sleep ".int($iSleep / $TelegrammeProSek).";; set $SELF AnzGAget $iAnzGAget",1);;\
fhem("sleep ".int($iSleep / $TelegrammeProSek).";; set $SELF AnzGAset $iAnzGAset",1);;\
fhem("sleep ".int($iSleep / $TelegrammeProSek).";; set $SELF AnzGAlistenonly $iAnzGAlistenonly",1);;\
fhem("sleep ".int($iSleep / $TelegrammeProSek).";; set $SELF AnzGAsetget $iAnzGAsetget",1);;\
fhem("sleep ".int($iSleep / $TelegrammeProSek).";; set $SELF AnzNosuffixIst $iNosuffix",1);;\
fhem("sleep ".int($iSleep / $TelegrammeProSek).";; set $SELF AnzAbfrageMax $iSleep",1);;\
fhem("sleep ".int($iSleep / $TelegrammeProSek).";; set $SELF AnzAbfrageIst 0",1);;\
fhem("sleep ".int($iSleep / $TelegrammeProSek).";; set $SELF AnzGA $iDevGesamt",1);;\
fhem("sleep ".int($iSleep / $TelegrammeProSek).";; set $SELF KNX_Aktualisierung_Zustand bereit",1);;\
fhem("sleep ".int($iSleep / $TelegrammeProSek).";; set $SELF KNX_Aktualisierung off",1);;\
} DOELSEIF ([$SELF:KNX_Aktualisierung] eq "off" and [?$SELF:KNX_Aktualisierung_Zustand] eq "WIP") (\
sleep 1;; set $SELF KNX_Aktualisierung on\
) DOELSEIF ([$SELF:KNX_Aktualisierung] eq "on" and [?$SELF:KNX_Aktualisierung_Zustand:sec] > 1200) (\
set $SELF KNX_Aktualisierung_Zustand bereit;; set $SELF KNX_Aktualisierung on\
)
attr di_KNX_Status_Aktualisierung do always
attr di_KNX_Status_Aktualisierung readingList KNX_Aktualisierung KNX_Aktualisierung_Zustand AnzAbfrageIst AnzAbfrageMax AnzGA AnzGAget AnzGAlistenonly AnzGAset AnzGAsetget AnzNosuffixIst
attr di_KNX_Status_Aktualisierung setList KNX_Aktualisierung:on,off KNX_Aktualisierung_Zustand:bereit,WIP
attr di_KNX_Status_Aktualisierung stateFormat state <br/> KNX_Aktualisierung_Zustand
attr di_KNX_Status_Aktualisierung userReadings ProzentAbfrage { if (ReadingsNum($NAME, 'AnzAbfrageMax', '') > 0) {int(100 * ReadingsNum($NAME, 'AnzAbfrageIst', '') / ReadingsNum($NAME, 'AnzAbfrageMax', ''))} else {0}}
attr di_KNX_Status_Aktualisierung webCmd KNX_Aktualisierung:ProzentAbfrage
attr di_KNX_Status_Aktualisierung widgetOverride ProzentAbfrage:slider,0,1,100
Hi,
eine erste Version, zum Testen.
Realisiert als 99_..Utils.pm, falls ok würde ich das als subroutine in KNX.pm einbauen.
Funktion:
-- scannt die definitionen, sucht nach dem Internal "GETSTRING" - das sind alle die kein set oder listenonly haben!
-- jedes get (auch mehrfache vom selben device) wird mit 100 ms verzögerung gestartet.
-- returncode: ANzahl gesendeter "get's"
Aufruf:scanKNX() # All devices
scanKNX('device-A') # nur device-A
scanKNX('dev-A, dev-B,dev-X') # devices A,B,X
## es geht aber auch alles was mit devspec funktioniert, z.b:
scanKNX('room=Kueche')
Aus der FHEM-CMD line mit {scanKNX('dev')} aufrufen...
l.g.erwin
PS: verbesserte Version....
Hi,
neue Version am SVN:
KNX_scan Utility - get devcie status from KNX-bus - detailed descripition -> cmdref
use a FHEM2FHEM device as IO-Device for KNX - description in wiki
minor corrections to cmd-ref
regards erwin
Grüße,
ich habe bestimmt einen Denkfehler.
Wenn ich folgendes in die FHEM-CMD line eingebe:
{KNX_scan()}
erhalte ich folgende Fehlermeldung:
Undefined subroutine &main::KNX_scan called at (eval 2110) line 1.
MMHHH,
sehr komisch, gestern hat's bei mir noch funktioniert, heute hab ich dasselbe Problem,
scheint als ob er die sub nicht findet...
Probiere bitte mal mit "vollständiger addressierung":
{FHEM::KNX::KNX_scan()}
sorry erwin
Zitat von: erwin am 08 Januar 2022, 11:32:08
Probiere bitte mal mit "vollständiger addressierung":
{FHEM::KNX::KNX_scan()}
Funktioniert
Ok, passt! Danke!
Ich werde heute abend eine neue Version einchecken- morgen früh im update...
l.g. erwin
Hallo Erwin,
stehe auf der Leitung warum dies bei mir nicht geht. Was mache ich falsch?
ERROR evaluating {FHEM::KNX::KNX_scan('room=AUSSEN')}: Undefined subroutine &FHEM::KNX::KNX_scan called at (eval 3940) line 1.
lg,
Matthias
Hi Matthias,
geht auch nicht (mehr), mit der aktuellen version....
Jetzt ist es so wie ursprünglich gewollt ;D .. und wie in der cmd-ref beschrieben...
{KNX_scan('room=AUSSEN')}
l.g. erwin
Hi Erwin,
hmm. Update und restart hatte ich gemacht..
2022.01.12 14:39:20 1: ERROR evaluating {KNX_scan('room=AUSSEN')}: Undefined subroutine &main::KNX_scan called at (eval 378552) line 1.
lg,
Matthias
Was ergibt ein: version 10_KNX ?
Wenn nicht so wie hier, dann war was mit dem update faul...
10_KNX.pm 25438 2022-01-08 18:16:22Z erwin
Danke Erwin für den Hinweis!
Hatte offensichtlich in der Vergangenheit hier ein exclude eingerichtet.
update: skipping FHEM/10_KNX.pm, matches exclude_from_update
Ich habe nur den Eintrag gesehen und dachte damit, dass hier diese Änderung im Update dabei sein sollte.
New entries in the CHANGED file:
- ....
- feature: 10_KNX: KNX_scan Utility function
- ....
Offensichtlich greift das exclude bei dem CHANGED File Inhalt nicht. Suboptimale Implementierung die mich etwas verwirrt hat.
Update hat geklappt trotz dieser Meldung:
2022.01.12 19:46:48 1: UPD FHEM/10_KNX.pm
2022.01.12 19:46:49 1: Got 100402 bytes for FHEM/10_KNX.pm, expected 97111
2022.01.12 19:46:49 1: aborting.
lg,
Matthias
Hi Matthias,
ZitatUpdate hat geklappt trotz dieser Meldung:
du hast offensichtlich noch Reste vom BETA-Test in deinem System...
Zusätzlich zu dem exclude from update, gibts noch was....
Die Lösung findest du im Ersten Beitrag dieser threads:
ZitatFür die user des beta-Moduls: Bitte die GIT Version NICHT MEHR verwenden!
l.g. erwin
Hallo,
ich weiß leider nicht, ob es an der neuen KNX Version liegt - aber wenn ich auf eine dpt14 Adresse per set, 0 schicke, kommt nichts an. Wenn ich 0.0 schicke dann schon.
Leider bekomme ich aber nur eine 0 von meinem Wechselrichter geschickt.
Weiß wer, wie ich das hinbekomme? Wenn ich dpt9 verwende klappt es - gibt es noch eine andere Lösung?
Danke
Du könntest dir bis zu einer Anpassung durch erwin mit einem User Reading helfen, welches aus 0 ein 0.0 macht und auf das Reading reagieren.
Aha. Danke. Das schau ich mir mal an.
Zitatset dpt14tst g1 0.0
...nein, liegt nicht an der neuen Version, das war immer schon falsch! ;D
Danke für's finden, gefixt. Ab morgen im update!
l.g. erwin
Hallo,
bei mir läuft inzwischen die neue Version sehr gut!
Ich habe jedoch noch ein Problem mit Szenen und zwar funktionieren nur einige.
Inzwischen habe ich herausgefunden, dass in ETS die Bit Szenen funktionieren, aber die Byte Szenen nicht.
Allerdings mit der alten KNX Version war das kein Problem. Da konnte ich ohne Probleme set Garten.Aus on senden und es hat funktioniert.
Im Event Monitor kommen dann 2 Einträge set Garten.Aus on und set Garten.aus setG1 on.
Wenn ich den Schalter betätige ist der einzige Unterschied, dass im Event Monitor statt setG1 getG1 gesendet wird.
Im FHEM command habe ich auch schon mal set Garten.Aus getG1 on getestet, aber hier passiert ebenfalls nix.
Hier mal ein List von Garten.Aus, was NICHT funktioniert und mit Byte definiert ist.
Internals:
DEF 6/0/5:dpt1
DEVNAME Garten.Aus
FIRSTGADNAME g1
FUUID 5c7ab74f-f33f-d8f3-52e8-6c608ec172eebd50
GETSTRING g1:noArg
IODev KNX
NAME Garten.Aus
NR 230
SETSTRING on:noArg off:noArg g1:on,off,toggle
STATE on
TYPE KNX
model dpt1
GADDETAILS:
g1:
CODE 06005
GROUP 6/0/5
MODEL dpt1
NO 1
OPTION
RDNAMEGET getG1
RDNAMEPUT putG1
RDNAMESET setG1
SETLIST :on,off,toggle
GADTABLE:
06005 g1
READINGS:
2022-02-07 10:38:30 IODev KNX
2022-02-07 10:38:30 getG1 on
2022-02-07 10:40:08 last-sender fhem
2022-02-07 10:40:08 setG1 on
2022-02-07 10:40:08 state on
2022-02-07 10:38:30 switch on
Attributes:
IODev KNX
devStateIcon on::off off::on
fhem_widget_channels [{"controlled_attribute":"on","color":"#0000FF","order":100,"alias":"Garten aus","allowed_values":["on"],"locations":["APP","WATCH"]}]
genericDeviceType switch
group Zentral
homebridgeMapping On:cmdOn=on,Off:CmdOff=off
room Widget,hidden
sortby 400
webCmd on:off
Und hier ein List einer Szene, die funktioniert und mit Bit definiert ist:
Internals:
DEF 6/0/3:dpt1
DEVNAME Wohnen.Stehlampen
FIRSTGADNAME g1
FUUID 5c7ab74f-f33f-d8f3-9a81-8d3d09f697901a03
GETSTRING g1:noArg
IODev KNX
KNX_MSGCNT 1
KNX_RAWMSG C0111cw0600300
KNX_TIME 2022-02-06 23:28:45
LASTInputDev KNX
MSGCNT 1
NAME Wohnen.Stehlampen
NR 233
SETSTRING on:noArg off:noArg g1:on,off,toggle
STATE off
TYPE KNX
model dpt1
GADDETAILS:
g1:
CODE 06003
GROUP 6/0/3
MODEL dpt1
NO 1
OPTION
RDNAMEGET getG1
RDNAMEPUT putG1
RDNAMESET setG1
SETLIST :on,off,toggle
GADTABLE:
06003 g1
READINGS:
2022-02-06 15:29:13 IODev KNX
2022-02-06 23:28:45 getG1 off
2022-02-06 23:28:45 last-sender 1.1.28
2022-02-06 17:16:47 setG1 on
2022-02-06 23:28:45 state off
Attributes:
IODev KNX
alexaName Stehlampen
alias Stehlampen
devStateIcon on::off off::on
genericDeviceType switch
group Zentral
homebridgeMapping On:cmdOn=on,Off:CmdOff=off
room Haus,Alexa
sortby 450
webCmd on:off
Ich vermute es liegt an dem dpt1. Evtl. müsste es dpt9 sein, aber dann weiss ich nicht, wie ich das mit dem on und off hinbekomme.
Wäre für Hilfe sehr dankbar!
Grüße, Roger
Hi Roger,
offengestanden werde ich nicht ganz schlau aus deinen Angaben.
Du sprichst von Szenen ?
Um welches KNX-Gerät geht es ?
für szenen kenn ich mehrere dpt's, z.b.
dpt1.022 (1 bit) on/off oder SzeneA/SzeneB
dpt17.001 (1 Byte: 0-63)
bpt18.001 (1 Byte: 1-64)
Der dpt, den du in fhem angibst, muss mit dem im Gerät übereinstimmen sonst kommt Unsinn oder nix raus... ich will sagen: "BYTE" szenen können nicht mit dpt1 funktionieren!
l.g. erwin
Hallo Erwin,
in ETS ist die Szene als Byte definiert, aber sie schaltet trotzdem nur ein oder aus.
Im FHEM konnte ich die Szene mit on und off steuern, aber nun geht das nicht mehr.
Wie Du schreibst passt das mit DPT1 nicht zusammen.
Also wenn ich das Device in FHEM jetzt umdefiniere in: dpt17.001
Kann ich dann trotzdem noch on und off verwenden?
Grüße, Roger
Hi,
dpt17.001: gültige Werte sind 0-63.
(Man könnte mittels eventmap ja von usr=on/off auf 0/? mappen.....)
Szenen schalten grundsätzlich nix, bevor sie nicht in den Aktoren definiert sind...
z.b.: Szene 5 schaltet Ausgang 2 im Aktor 1 auf off UND Ausgang 1 im Aktor 3 auf on, usw.... Das muss alles per ETS vorab programmiert sein.
Vorschlag: definiere mal das device um auf dpt17.001, und dann schicke mal 0, und danach 1 ,... evtl. im ETS Monitor mitschauen, was passiert...
Um welche Gerät geht es?
l.g. erwin
Hallo Erwin,
SUPER das wars!
dpt17.001 und eventMap 1:on 0:off
Danke & Grüße,
Roger
Hallo Kollegen
sehr gut das das KNX Modul weiterlebt und auch erweitert wurde z.B um den dpt20.102 HVAC mode, danke.
Nun genau zu diesem DPT ein kleines Problem: Ich habe einen MDT Heizungsaktor der den HVAC Staus z.B. für den Komfortbetrieb den Wert 21 (20 für Heizen + 1für den Komfortbetrieb) sendet.
Der Hexwert 21 kommt in Fhem auch an, wird aber nicht richtig ausgewertet.
#######
KNX_Parse -process: IO-name: KNX_EIBD, device-name: OG_Essen_Lesen_Klima, rd-name: g6, gadCode: 03708, cmd: w
KNX_decodeByDpt -enter: model: dpt20.102, code: dpt20, value: 21, length-value: 2
KNX_decodeByDpt -exit: model: dpt20.102, code: dpt20, value: 21, state: reserved
#######
Mache ich etwas falsch? Bin um Tipps dankbar.
Danke und Gruss
Remo
Hi Remo,
du machst nichts falsch, ausser du verwendest den dpt20.102 und in der MDT dokumentation steht ein anderer dpt!
ich werte dzt. für diesen dpt nur die Werte 0-4 aus -> Auto Comfort Standby Economy Protection, so ist im KNX-standard definiert.....(siehe screenshot)
Alle Werte > 4 werden mit reserved übersetzt!
Die Frage ist:
hast du eine Doku, wo das genau beschrieben ist?
l.g. erwin
Hallo Erwin
danke für deine schnelle Antwort. In der Dokumentation des MDT Heizungsaktors steht:
Ok, nachdem ich jetzt weiß um welchen KNX-Aktor es geht, wird es einfacher:
ZitatIn der Dokumentation des MDT Heizungsaktors steht:
... unter anderem auch,
daß das Status Object entweder nach KNX-Standard dpt20.102 oder proprietär ausgegeben werden kann.
Diese Einstellung kann mit einem ETS-Parameter geändert werden.
Es ergeben sich somit 3 Möglichkeiten:
1) Du änderst die ETS-Einstellung
2) Ich ändere das decoding, damit Werte größer 16 ausgeblendet werden -> das würde bei einem 0x21 (bei dir) dann "Comfort" als reading-value ergeben - und wäre standardkonform.
3) Ich kombiniere den Status. Das würde bei einem 0x21 (bei dir) dann "Comfort_Heating" als reading-value ergeben - und wäre NICHT standardkonform. ich müsste dan konsequenterweise bei einem 0x01 dann "Comfort_Cooling" als reading-value ausgeben und dass wäre für jene Aktoren die sich an den Standard halten FALSCH!
ich tendiere zu Variante 1 oder 2.
l.g. erwin
Hallo Erwin
ich würde auch die Variante 2 bevorzugen, also das Auswerten des unteren nibbles, dann wäre es glaub nahe am Standart und für viele Benutzer brauchbar. Leider bin ich kein Perl Programmierer, sorry.
gruss Remo
Hi,
Variante 2 würde so aussehen (ab zeile 1818 in 10_KNX.pm) :
sub dec_dpt20 { #HVAC
my $numval = hex (shift);
$numval = ($numval & 0x0f); # <- das ist die Änderung !!!
Falls du dir die Änderung zutraust, bitte versuchen! anschließen shutdown/restart machen...
Ich könnte, wenn von dir Bedarf besteht, den zusätzlichen RHCC Status (DPT 22.101) implementieren.... (siehe mein vorheriger screenshot....)
l.g.erwin
Hallo Erwin
funktioniert perfekt, vielen Dank
Gruss Remo
Hi Remo,
good news, dann kann ich mir noch etwas Zeit lassen mit der neuen Version ;D
In der nächsten Version wird das drinnen sein.
Ich teste gerade den dpt22.101 und ein paar kleinere Änderungen....
l.g. erwin
Hi KNX community!
neue Version ist am SVN, change-history im 1.Beitrag in diesem Thread!
l.g. erwin
Hi KNX community!
neue Version ist am SVN, change-history im 1.Beitrag in diesem Thread!
l.g. erwin
Hi KNX community!
neue Version ist am SVN, change-history im 1.Beitrag in diesem Thread! (minor additions to cmdref & some cleanup)
l.g. erwin
Kann es sein, dass bei KNX_eval das $hash kaputt gegangen ist? Ich verwende folgendes stateCmd:
{
if ($gadName eq "Helligkeit")
{
my $s = $state =~ s/ lux//r;
my $newVal = $s * 10;
fhem("set $name Helligkeit10 $newVal");
readingsBeginUpdate(%hash);
}
return ReadingsVal($name, "Helligkeit", "");
}
um bei einem einkommenden Wert diesen verzehnfacht wieder auf einem anderen GroupObj den Bus zu jagen. Nun mosert er aber über unbekannte Variable $hash. Nehme ich %hash, dann mosert er
2022.07.25 21:59:37 1: ERROR evaluating my $gadName= $evalSpecials->{'%gadName'};my %hash=%{$evalSpecials->{'%hash'}};my $name= $evalSpecials->{'%name'};my $state= $evalSpecials->{'%state'};{
if ($gadName eq "Helligkeit")
{
my $s = $state =~ s/ lux//r;
my $newVal = $s * 10;
fhem("set $name Helligkeit10 $newVal");
readingsBeginUpdate(%hash);
}
return ReadingsVal($name, "Helligkeit", "");
}: Can't use string ("27") as a HASH ref while "strict refs" in use at fhem.pl line 4818.
Hi,
Ich kann jetzt nicht testen (offline Urlaub),
Du brauchst kein readingsbeginupdate... nach einem fhem(,,set ...
Und ,,Return $state;" sollte reichen.
L.g.Erwin
Mache ich das reaginsBeginUpdate nicht, dann wirft er mir entsprechende Fehler ins Log. Vermutlich weil der vorherige fhem-set auch ein Reading aktualisiert und das laufende Update dann beendet. Helligkeit wurde dadurch dann wenn ich mich recht erinnere auch nicht gesetzt.
Mache ich nur "return $state", dann aendert sich State mit jedem der zugeordneten Objekte. Er zeigt dann also den 10-fachen Wert an, von Helligkeit10.
Eilt aber nicht, geniess den Urlaub! Vielleicht find ich in der Zwischenzeit auch die Loesung, wenn ich mich nochmal mit Perl und seinen Typen auseinander setz.
Hi,
ein erster Test:
my $s = $state =~ s/ lux//r;
ergibt einen syntax error, damit sind alle nachfolgenden Berechnungen kaputt! und selbst wenn ich den syntax error korrigiere kommt für $s immer 0 oder 1 heraus (match/nomatch)!
ein readingsBeginUpdate darfts du dort nicht machen, weil zu diesem Zeitpunkt läuft bereist ein readingsBeginUpdate, und falls doch, musst du auch ein readingsEndUpdate machen, sonst kommen alle internen strukturen durcheinander....
Das ist aber gar nicht nötig !
Falls ich dich richtig verstanden habe, willst du aus einem vom Bus kommenden event "Helligkeit" - den 10fachen wert auf eine andere GA im selben FHEM device schicken.
Das könnte beispielhaft so aussehen:
defmod dpt9004 KNX 14/3/9:dpt9.004:Helligkeit:listenonly 14/4/9:dpt9.004:Helligkeit10
attr dpt9004 IODev myKNXIO
attr dpt9004 stateCmd {\
if ($gadName eq 'Helligkeit')\
{\
# my ($newVal) = $state =~ /([-+\d\.]+).*/ix;;\
my $newVal = (split(' ',$state))[0];;\
$newVal *= 10;;\
Log3 undef, 1, "Helligkeit = $state H10 = $newVal";; \
fhem("sleep 0.1;;set $name Helligkeit10 $newVal");;\
}\
\
return $state;;\
}
... exportiert mit raw definition ! Falls du das im statecmd im detail-view eingeben willst: Aus den 2fachen ;; -> einfache Strichpunkte machen, und \ bedeutet newline!
Kommentar zum code:
2 Varianten um aus "xxx lux" -> "xxx" zu machen, beide haben den charme dass sie alles ignorieren was nach dem 1sten blank kommt.
fhem("sleep 0.1;set $name..... -> zuerst wird das ankommende reading komplett verarbeitet, dann erst erfolgt ein "set..." auf das neue reading- value.
Ganz wichtig: das neue reading: (im Bsp: Helligkeit10) muss in der definition existieren, sonst ergibt das chaos!
Tip: das reading "Helligkeit" mit listenonly spezifizieren, damit niemand in Verlegenheit kommt, das von FHEM aus zu setzen!
Letzte Bemerkung: falls den neue wert größer 670000 wird, wird intern auf 670000 geklippt! (max wert von dpt9)
l.g. erwin
Hi zusammen,
ich habe auf das aktuellste KNX/fhem geupdated und habe mir in diesem Zusammenhang auch mal das neue Wiki angeschaut, um ein paar Ideen zu bekommen, wie ich meine Dimmbaren Lampen, sowohl über die WebUI als auch über die HandyUI steuern kann. Also Ein/Aus und Irgendwie Dimmwert festlegen.
Für die WebUI ist mir das mit untem stehenden Code (adaptiert aus dem neuen KNX Wiki) gelungen. Die Ergebnisse könnt Ihr in den folgenden Screenshots sehen:
WebUI (https://abload.de/img/unbenannt_1l8fay.jpg)
HandyUI (https://abload.de/img/unbenannt_2uui33.jpg)
Ich bräuchte jetzt allerdings noch ein paar Gedankenanstöße, wie ich das besser hinbekommen:
* WebUI: Icon (Bspw. Lampe) für ein/aus weider einblenden.
* Steuerung auch über HandyUI. Eine 1-Tasten Bedienung wäre schön: Du drückst auf die Lampe. Dann dimmt es hoch oder runter solange bis du wieder auf die Lampe drückst
Die KNX-Adressen für ein/aus und Rückgabe status ein/aus sind 1/1/10:dpt1:EinAus und 1/4/10:dpt1:Status:listenonly.
defmod WOH.WL_Ost KNX 1/3/10:dpt5.001:Dimmen:set:nosuffix 1/5/10:dpt5.001:DimmStatus:get:nosuffix
attr WOH.WL_Ost IODev KNX
attr WOH.WL_Ost room KNX,Wohnen
attr WOH.WL_Ost stateCmd { fhem "sleep 0.05 quiet;; setreading $name Dimmen $state" if ($gadName eq 'DimmStatus');; return $state;; }
attr WOH.WL_Ost webCmd Dimmen
attr WOH.WL_Ost widgetOverride Dimmen:slider,0,5,100
Lieben Dank
Hi Thomas,
... cool das du das wiki liest!
ad. HandyUI: da wird KEIN Webcmd angezeigt - ich nehme an du hast diese FHEMWEB-Instanz mit attribut smallscreen od iossmallscreen,... definiert.... (das ist ein FHEM-weite Funktion, hat nix mit KNX zu tun. (siehe wiki: webCmd - Einschränkungen)
ad. WebUI: wenn ich dich richtig verstehe, willst du in deinem gezeigten device WOH.WL_Ost zusätzlich die GA's für on/off haben ?
Das könnte dann so aussehen:
defmod WOH.WL_Ost 1/1/10:dpt1:EinAus:set:nosuffix 1/4/10:dpt1:Status:listenonly:nosuffix KNX 1/3/10:dpt5.001:Dimmen:set:nosuffix 1/5/10:dpt5.001:DimmStatus:get:nosuffix
attr WOH.WL_Ost devStateIcon off:li_wht_off:on on:li_wht_on:off 0.*:li_wht_off:on \d+.*:li_wht_on:off
das devStateIcon wird "on" wenn im state-reading "on" oder eine Zahl > 0 steht. Beim draufklicken wird jeweils ein on bzw. off cmd auf die GA EinAus gesendet.
"EinTasten" Hoch/runter-dimmen würde mit einem Timer funktionieren, das ist allerdings eher komplex...
Eine "dimup" und "dimdown"-Taste würde eher realisierbar sein - z.b. jeder klick um +/-10%... ...mit webCmd realisierbar
Edit: habs gefunden...:
attr <FHEMWEB> smallscreenCommands 1 --> gesetzt im FHEMWEB der HandyUI -> commands, slider and dropdown menues will appear in smallscreen landscape mode.
l.g. erwin
Danke für den Input.
Insbesondere wusste ich noch nicht, dass wenn ich das Handy queer halte, die Schieberegler usw wieder eingeblendet werden.
So kann ich ggf. das Lampensymbol haben und daneben den Schieberegler zum Einstellen des Dimmwertes.
Allerdings bietet der Dimmaktor (Siehe Bild im Anhang) auch eine Ein-Tasten-Steuerung. Das ist ja ein etwas anderer Datentyp als ein/aus - könntest Du mir hier noch einen Tipp geben, wie ich diese KNX-Gruppenadresse ansteuere? Wenn ich das ähnlich wie bei EinAus ansteuere, dann bewirkt das bei der Lampe nichts.
Bei meinen KNX Tastern drücke ich dann einfsch lange auf den taster - dann dimmt es schrittweise hoch - wenn ich nochmal lange draufdrücke dann dimmt es runter. ich dachte soetwas könnte ich analog auch in fhem realisieren - aber notfalls dann wie oben beschrieben mit lampe und daneben einen slider. mal gucken, ob ich das hingebastelt bekomme ;)
UPDATE:
Habe jetzt einmal die Variante mit Lampe und Slider daneben umgesetzt. Die Lampe zeigt den aktuellen Dimmwert an. Wenn ich draufklicke geht es an oder aus jenach aktuellem Zustand. Zwei Sachen gefallen mir noch nicht so ganz (Siehe auch Bild im Anhang):
1) Wenn ich auf die Lampe klicke, um vom Zustand Aus einzuschalten, zeigt das Lampensymbol erstmal on an - und nach ein paar sekunden zeigt es erst den aktuellen Dimmwert an - gibt es da einen trick, das anzupassen?
2) der Slider ist nicht bündig mit den anderen Slidern von den Rolläden bspw. kann man das irgendwie ausrichten?
defmod WOH.WL_Ost1 KNX 1/1/10:dpt1:Schalten:set:nosuffix 1/4/10:dpt1:SchaltenStatus:listenonly:nosuffix 1/3/10:dpt5.001:DimmWert:set:nosuffix 1/5/10:dpt5.001:DimmWertStatus:get:nosuffix
attr WOH.WL_Ost1 IODev KNX
attr WOH.WL_Ost1 devStateIcon off.*:light_light_dim_00:on 0.*:light_light_dim_00:on 1\d.*:light_light_dim_10:off 2\d.*:light_light_dim_20:off 3\d.*:light_light_dim_30:off 4\d.*:light_light_dim_40:off 5\d.*:light_light_dim_50:off 6\d.*:light_light_dim_60:off 7\d.*:light_light_dim_70:off 8\d.*:light_light_dim_80:off 9\d.*:light_light_dim_90:off 100.*:light_light_dim_100:off [1-9].*:light_light_dim_10:off
attr WOH.WL_Ost1 icon light_wall_2
attr WOH.WL_Ost1 room KNX,Wohnen
attr WOH.WL_Ost1 stateCmd { fhem "sleep 0.05 quiet;; setreading $name DimmWert $state" if ($gadName eq 'DimmStatus');; return $state;; }
attr WOH.WL_Ost1 webCmd DimmWert
Hi,
ZitatBei meinen KNX Tastern drücke ich dann einfsch lange auf den taster ....
Ok, das ist eine Funktion des Tasters, der sendet bei langem Tastendruck eine andere GA wie bei einem kurzen Tastendruck (und wiederholt das solange gedrückt bleibt...) - Um das zu verifizieren, könnte man mit dem ETS-GAMonitor zuschauen, welche Messages beim drücken kommen.
ZitatAllerdings bietet der Dimmaktor (Siehe Bild im Anhang) auch eine Ein-Tasten-Steuerung
du meinst die GA 1/2/10 ?
... die ist mit 4 bit spezifiziert, ich nehme daher an, es ist ein dpt3 (in der doku vom dimmer nachschauen?)
ich würde als ersten test mal das als "extra" device definieren und schauen was passiert
defmod dpt3test KNX 1/2/10:dpt3l.g.erwin
ZitatWenn ich auf die Lampe klicke, um vom Zustand Aus einzuschalten, zeigt das Lampensymbol erstmal on an - und ...
3 Möglichkeiten:
1) im devStateIcon einen entry für on:xxx:yyy machen (der fehlt in deinem Post) - deswegen zeigt er das Wort on an.
2) attr <device> stateRegex /Schalten// /SchaltenStatus// -> damit verhinderst du, dass ein on od. off ins state-reading kommt und damit von DevstateIcon verarbeitet wird.
3) attr <device> stateFormat DimmWertStatus -> damit kommt nur der Wert von DimmWertStatus ins Internal STATE und damit ins DevstateIcon - ist am elegantesten!
Zitatder Slider ist nicht bündig mit den anderen Slidern
.. FHEMWEB Angelegenheit.... weil du bei den Rolläden neben dem devStateIcon auch noch cmd-buttons definert hast. Evtl. hilft dir attr DevStateStyle die wdth vom devStteIcon größer zu machen.
l.g. erwin
Danke nochmal für Deine Hilfe. Mit dem Endergebnis bin ich jetzt sehr zufrieden. Auch meiner Frau gefällts gut ;)
defmod WOH.WL_Ost KNX 1/1/10:dpt1:Schalten:set:nosuffix 1/2/10:dpt3.007:DimmSchritt:set:nosuffix 1/3/10:dpt5.001:DimmWert:set:nosuffix 1/4/10:dpt1:SchaltenStatus:listenonly:nosuffix 1/5/10:dpt5.001:DimmWertStatus:get:nosuffix
attr WOH.WL_Ost IODev KNX
attr WOH.WL_Ost devStateIcon off.*:light_light_dim_00:on 0.*:light_light_dim_00:on 1\d.*:light_light_dim_10@orange:off 2\d.*:light_light_dim_20@orange:off 3\d.*:light_light_dim_30@orange:off 4\d.*:light_light_dim_40@orange:off 5\d.*:light_light_dim_50@orange:off 6\d.*:light_light_dim_60@orange:off 7\d.*:light_light_dim_70@orange:off 8\d.*:light_light_dim_80@orange:off 9\d.*:light_light_dim_90@orange:off 100.*:light_light_dim_100@orange:off [1-9].*:light_light_dim_10@orange:off
attr WOH.WL_Ost group Beleuchtung
attr WOH.WL_Ost icon light_wall_2
attr WOH.WL_Ost room KNX,Wohnen
attr WOH.WL_Ost sortby 5
attr WOH.WL_Ost stateCmd { fhem "sleep 0.05 quiet;; setreading $name DimmWert $state" if ($gadName eq 'DimmStatus');; return $state;; }
attr WOH.WL_Ost stateFormat DimmWertStatus
attr WOH.WL_Ost webCmd DimmWert
Hi Erwin,
ich habe im Log folgende Einträge.
Wie finde ich das dazugehörige Device ohne viel Aufwand?
2022.10.14 10:47:20 2: KNX_Get: too much arguments. Only one argument allowed (group-address). Other Arguments are discarded.
2022.10.14 10:47:47 2: KNX_Get: too much arguments. Only one argument allowed (group-address). Other Arguments are discarded.
lg,
Matthias
Hi Matthias,
1) präpotente Antwort: auf die nächste version warten.... (hoffentlich nächste Woche)
2) bessere Antwort: im code die zeile mit
ZitatLog3 ($name, 2, "KNX_Get: too much arguments. Only one argument allowed (group-address). Other Arguments are discarded.") if (int(@a) > 2);
ersetzen durch:
Log3 ($name, 3, qq{KNX_Get ($name): too much arguments. Only one argument allowed (gadName). Other Arguments are discarded.}) if (int(@a) > 2);3) in notifies/doif's suchen, wo ein get auf ein KNX-device vorkommt.....
l.g. erwin
Hallo Erwin,
vielen Dank schon mal vorab. Ich warte auf die neue Version. Das ist mir bei so einem Thema ausreichend schnell. Trotzdem gut zu wissen wie man es sofort lösen könnte.
DOIF durchschauen wäre eine Option. Aktuell habe ich 120 DOIFs + ein paar Notifies in meinem System. Da schaue ich lange .... Der Device Name im Logeintrag ist daher einfach unschlagbar.
lg,
Matthias
Hi KNX community!
neue Version ist am SVN, change-history im 1.Beitrag in diesem Thread!
Auch wenn nur einige Funktionen neu sind / geändert wurden, durch cleanup und performance tuninig sind insgesamt 500+ Zeilen code modifiziert worden!
Ich bitte daher um feedback....
l.g. erwin
Hallo Erwin,
vielen Dank für das Update. Bis jetzt läuft alles soweit ohne große Probleme. Die Devicenamen sind jetzt auch immer in den Logs vorhanden - super!
Ein Problem habe ich aber entdeckt mit einem Device. Dieses brauche ich um an einem MDT Display Zusatzinfos anzuzeigen.
defmod Statusanzeige KNX 0/5/35:dpt16
attr Statusanzeige IODev KNX
Wenn ich den Wert zb "Aussen 12.6°C" übergebe, dann wurde dieser immer so ausgegeben. Seit dem Update sehe ich aber folgenden String am MDT Display: "Aussen 12.6?C".
Hat sich hier ein Fehler eingeschlichen?
lg,
Matthias
Hi Matthias,
ZitatHat sich hier ein Fehler eingeschlichen?
..könnte sein, da hab ich was geändert... ;D
Bitte versuch mal mit dpt16.001
falls erfolgreich, werde ich das ausbessern...
l.g. erwin
Hi Erwin,
diese Änderung hat das Problem gelöst. Soll ich das so lassen, oder war das nur ein Test?
lg,
Matthias
Lass es so, das ist komplett richtig!
Dein KNX-display verwendet ISO-8859-1 codierung, das war ursprünglich der default für dpt16 im KNX-Modul.
Durch meine "optimierung" wurde dieser default auf "ascii" -> entspricht dpt16.000 geändert....
... in ascii gibts aber kein GRAD symbol...
Wird in der nächsten version korrigiert, möchte aber noch bis nächste Woche auf evtl. weiteres Feedback warten.
l.g. erwin
Perfekt Danke!
lg
Matthias
Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
l.g. erwin
Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
l.g. erwin
Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
l.g. erwin
Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
Durch die verzögerte definition der KNX-devices kommen jetzt beim starten von FHEM Log-messages für devices die:
MODEL_NOT_DEFINED in der definition haben.
l.g. erwin
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
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
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!
Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
l.g. erwin
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
Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
l.g. erwin
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
Hi Beko136
Bin dzt. auf Urlaub, bitte um Geduld bis nächste Woche
L.g. 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 (https://wiki.fhem.de/wiki/KNX_Device_Definition_-_Beispiele) dazu!
Auch hier dokumentiert: Migration EIB-KNX (https://forum.fhem.de/index.php?topic=126994.0)
l.g. 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
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
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
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?
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 (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
Zitat von: erwin am 28 Juni 2023, 08:49:07ZitatDoch! 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 (https://forum.fhem.de/index.php?topic=133667.0)
... war übrigens dein Thread!
Ummm...
Wie Du im letzten Absatz von diesem Beitrag (https://forum.fhem.de/index.php?msg=1276563) 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... :-(
Hmmm,
geschrieben hab ich:
Zitatre KNX_scan: hab ich noch nie in Kombination mit TUL- oder KNXTUL-Modul getestet....
update: KNX_scan geht mit TUL und KNXTUL definitiv nicht, weil es bei diesen Modulen kein reading state:connected gibt. Muss mir überlegen, ob ich das implementierfen will...., alternativ cmd-ref Hinweis dazu schreibe.
und einen fix für TUl / KNXTul werde ich sicher nicht machen, weil:
1) ich nicht der Maintainer dieser Module bin. Daher "darf" ich das gar nicht!
2) meine Zeit lieber in jene Module investiere, wo ich es sinnvoll finde.
3) ich hab nie von einem fix gesprochen, ich hab lediglich begründet, warum es mit diesen Modulen nicht funktioniert.
4) es eine Alternative für diese Module gibt, die seit 2018 nicht mehr gewartet wurden.
PS: ich hab mich für den cmd-ref Hinweis entschieden, ich hoffe das ist eindeutig!
Mit lokalen Änderungen an Modulen wird der support sehr mühsam!
ZitatHat wunderprächtig funktioniert, bis Dein richtiger "fix" kam... :-(
...auch wenn du es wiederholst: es hat nicht funktioniert, siehe: https://forum.fhem.de/index.php?topic=133667.0 (https://forum.fhem.de/index.php?topic=133667.0)
Fassen wir zusammen:
Es hat vor dem Fix nicht funktioniert.
Es funktioniert nach dem Fix nicht.
Was hat de Fix gebracht?
Zitat von: erwin am 28 Juni 2023, 18:11:00Mit lokalen Änderungen an Modulen wird der support sehr mühsam!
Die lokalen Änderungen haben den Hintergrund dass ich dabei bin, das Modul komplett zu überarbeiten. Das läuft mittlerweile mit dem TPUART-Interface sauber und stabil und auch schlank ganz ohne Umwege über den knxd-Moloch.
Ich frage mich aber mittlerweile, ob das eine gute Idee war...
Dann fasse ich auch zusammen:
Es funktioniert mit diesem fix wie in der cmd-ref beschrieben.
seltsam ist dein letzter post:
ZitatEs hat vor dem Fix nicht funktioniert.
... am 27.6. hast du geschrieben:
ZitatDoch! Es hatte funktioniert! bis zu dem "fix"...
Ich kenn mich nicht mehr aus. ;D
Zitat von: erwin am 29 Juni 2023, 07:35:47Es funktioniert mit diesem fix wie in der cmd-ref beschrieben.
Mit KNXTUL?
Zitatseltsam ist dein letzter post:
ZitatEs hat vor dem Fix nicht funktioniert.
... am 27.6. hast du geschrieben:
ZitatDoch! Es hatte funktioniert! bis zu dem "fix"...
Ich kenn mich nicht mehr aus. ;D
Was bitte ist daran seltsam? Ich hatte doch alles erläutert.
Es hatte funktioniert, mit der einen zusätzlichen Zeile in KNXTUL, wie in #119 geschrieben. Diese Zeile liefert das erforderliche Connect-event.
Bei Dir hingegen, hat es mit KNXTUL weder vor dem Fix funktioniert, noch nach dem Fix.
Und jetzt funktioniert es mit KNXTUL eben
nicht mehr, auch nicht mit dieser Connect-Zeile.
Es bleibt die Frage, was der Fix (also das Verschieben der Funktionalität in KNXIO) gebracht hat und welchen Zweck er erfüllen soll?
Der Scan ist eine generelle Funktionalität, die nicht abhängig von irgend einem bestimmten IO-Device ist. Das einzige, was vom IO-Device kommen muss ist das connect-/disconnect event. Der Rest des Scan-Vorgangs hat rein gar nichts mit dem IO-Device zu tun und gehört somit auch nicht dort hin.
Insbesondere sind die Kommunikationsobjekte (also das, worum sich der scan kümmern soll) nicht im IO-Device angesiedelt, sondern im KNX-Modul. Da gehört die Scan-Funktionalität auch hin.
Just my $0.02...
ZitatMit KNXTUL?
NEIN...auch nicht mit TUL: siehe cmd-ref
Zitates hatte funktioniert, mit der einen zusätzlichen Zeile in KNXTUL, wie in #119 geschrieben. Diese Zeile liefert das erforderliche Connect-event.
Wenn man mit gepatchen Modulen argumentiert, kann man jeden support ad absurdum führen.
ZitatEs bleibt die Frage, was der Fix (also das Verschieben der Funktionalität in KNXIO)...
KNX_scan ist ein neues Utility, und um die Diskussion zu vermeiden, warum das mit TUL/KNXTUL nicht geht... und ich keinen support für diese Module leisten kann/will!
Ich gebe dir aus Architektur-Sicht recht, hätte die Funktion im KNX Modul belassen können und die IO-dev TUL/KNXTUL mittels error-msg ausschließen...
Aber ich wiederhole mich: cmd-ref lesen, falls irgendwas dort beschriebene nicht funktioniert, gebe ich gern support!
Zitat von: erwin am 29 Juni 2023, 19:15:07ZitatMit KNXTUL?
NEIN...auch nicht mit TUL: siehe cmd-ref
Ähm, ich muss mich an dieser Stelle korrigieren: ich verwende/überarbeite nicht KNXTUL, sondern TUL.
Das aktuell in fhem enthaltene TUL ist tatsächlich komplett kaputt. Der Autor des Moduls hatte offensichtlich das Datenblatt des tpuart-Chips entweder nicht gelesen oder nicht verstanden.
Das ist auch der Grund, warum ich das von Grund auf neu schreibe.
Dass ich das in einem halb-fertigen Zustand nicht veröffentlichen will wirst Du hoffentlich nachvollziehen können.
ZitatWenn man mit gepatchen Modulen argumentiert, kann man jeden support ad absurdum führen.
Es geht nicht um ein gepatchtes Modul, sondern um ein komplett überarbeitetes bzw neu geschriebenes. Das nur nebenbei.
Und ich argumentiere auch nicht damit. Es gibt schlicht keinen vernünftigen Grund diese Funktionalität in das IO-Modul zu verschieben. Sonst müsste jedes Modul diese Funktionalität duplizieren. Auch die Kommunikationsobjekte, um die sich der scan ja kümmert, sind nicht im IO-Modul beheimatet sondern im KNX-Modul.
Es geht auch nicht um Support: die Zeile mit dem connect konnte ich auch selbst hinzufügen.
Und ich kann Dir versichern, dass aktuell ausser mir niemand TUL verwendet. Ganz einfach aus dem Grund, dass das mit fhem aktuell ausgelieferte Modul schlicht nicht funktioniert -- zumindest nicht mit tpuart. Und wer NICHT tpuart verwendet, für den gibt es auch keinen Grund nicht auf KNXIO umzusteigen.
Insofern ist also auch keine Flut von Support-Anfragen zu erwarten.
Und nein: für mich ist es keine Option auf KNXIO umzusteigen, weil mein KNX-Router verschlüsselt kommuniziert und weder KNXIO noch knxd das können...
ZitatKNX_scan ist ein neues Utility, und um die Diskussion zu vermeiden, warum das mit TUL/KNXTUL nicht geht... und ich keinen support für diese Module leisten kann/will!
Nun, es gibt keinen Grund warum andere IO-Devices nicht mit dem scan funktionieren sollten -- sofern sie überhaupt funktionieren. Der scan macht nichts anderes als die stinknormale KNX-Kommunikation ebenfalls. Die einzige zusätzliche Voraussetzung ist der connect.
ZitatIch gebe dir aus Architektur-Sicht recht, hätte die Funktion im KNX Modul belassen können und die IO-dev TUL/KNXTUL mittels error-msg ausschließen...
Nein, auch keine error-msg. Einfach so belassen wie es war. Lediglich in der Doku zum KNX-Modul die anderen Module als "deprecated" erklären.
Falls dein neu geschriebenes Modul irgendwann mal im SVN zu finden ist, bin ich gerne bereit,
die Funktion wieder ins KNX-Modul zu verschieben, auch wenn das etwas Aufwand bez. dem neuen Attr. enableKNXscan im KNXIO Modul bedeutet.
Solange es nur EIN IO-Modul gibt, das (in der SVN-version) das unterstützt, ist es relativ egal, wo die Funktion sitzt. Streng genommen ist es im KNX-Modul unnötiger/nicht funktionaler code, falls TUL/KNXTUL als IO-dev verwendet wird.
Und lt. Statistik von heute verwenden etwa 90 user das TUL-Modul, wieviele davon mit TP-UART ? keine Ahnung, jedenfalls wurde schon 2018 davon abgeraten und via knxd empfohlen, weil hier das TP1 protokoll nicht vollständig implementiert ist...(Ack, error-recovery).
ZitatEs geht auch nicht um Support: die Zeile mit dem connect konnte ich auch selbst hinzufügen.
Das du die Zeile hinzufügen kannst, glaube ich dir! Es geht dann sehr wohl um den support: Jeder support geht davon aus, dass es sich um ein Problem mit dem aktuellen code aus dem SVN handelt!
Bin schon gespannt auf deine Implementation mit Verschlüsselung.
Zitat von: erwin am 29 Juni 2023, 22:48:45die Funktion wieder ins KNX-Modul zu verschieben, auch wenn das etwas Aufwand bez. dem neuen Attr. enableKNXscan im KNXIO Modul bedeutet.
Dieses Attr wäre doch wohl ebenfalls besser im KNX-Modul aufgehoben?
ZitatSolange es nur EIN IO-Modul gibt, das (in der SVN-version) das unterstützt, ist es relativ egal, wo die Funktion sitzt.
Mit dieser Argumentation kannst Du auch gleich KNX und KNXIO zu einem Modul zusammenwürfeln...
ZitatStreng genommen ist es im KNX-Modul unnötiger/nicht funktionaler code, falls TUL/KNXTUL als IO-dev verwendet wird.
???
Eben nicht!
ZitatBin schon gespannt auf deine Implementation mit Verschlüsselung.
Eben
NICHT mit Verschlüsselung, sondern ein funktionierendes tpuart, das DIREKT mit dem Bus verbunden ist. Nix knxd, nix Ethernet, nix Router, nix Verschlüsselung.
Aber ich lerne ja gerade, wie gross Teamarbeit hier geschrieben wird. Bin mir nicht mehr so ganz sicher ob ich in einem Team mitspielen will wo man sich bewusst gegenseitig Steine in den Weg legt...
Schönen Tag noch...
ZitatEben NICHT mit Verschlüsselung, sondern ein funktionierendes tpuart, das ...
aber einen Tag vorher:
ZitatUnd nein: für mich ist es keine Option auf KNXIO umzusteigen, weil mein KNX-Router verschlüsselt kommuniziert und weder KNXIO noch knxd das können...
... bin verwirrt und gebe auf!
Das Angebot einer Kooperation steht nach wie vor!
Zitat von: erwin am 30 Juni 2023, 07:22:50ZitatEben NICHT mit Verschlüsselung, sondern ein funktionierendes tpuart, das ...
aber einen Tag vorher:
ZitatUnd nein: für mich ist es keine Option auf KNXIO umzusteigen, weil mein KNX-Router verschlüsselt kommuniziert und weder KNXIO noch knxd das können...
... bin verwirrt und gebe auf!
Hättest Du mal die Beiträge die Du zitierst gelesen, dann wäre auch keine Verwirrung entstanden.
Hier also noch einmal:
Mein KNX-Router verschlüsselt. Und das bleibt auch so, weil ich
keine unverschlüsselte Kommunikation im (W)LAN haben will. Schon gar nicht will ich unverschlüsselte Kommunikation im (W)LAN haben, über die man auf die Hausautomatisierung zugreifen kann.
Weder KNXIO noch knxd können Verschlüsselung. Somit ist ein Umstieg auf KNXIO keine Option.
Das tpuart-Modul (das den KNX-Bus
direkt auf einem USB-Port zur Verfügung stellt) ist sehr wohl eine Option, weil hier die Kommunikation
nicht über (W)LAN geht und somit nicht zwangsläufig verschlüsselt sein muss.
ZitatDas Angebot einer Kooperation steht nach wie vor!
Hmmm..
Also bislang stellt sich die "Kooperation" für mich so dar, dass aus Architektur-Sicht unsinnige Änderungen vorgenommen werden nur um Fremdmodule von der Zusammenarbeit auszuschliessen (https://forum.fhem.de/index.php?msg=1280120)
Eine ähnliche Art von "Kooperation" scheint auch hier (https://forum.fhem.de/index.php?topic=133708.0) vorzuliegen. Dort wurde ja auch offensichtlich die (eigentlich sinnvolle) Funktionalität zunächst im KNX eingebaut. Aber anstatt diese Funktionalität in den Kern zu verschieben damit es alle Module
auf gleiche Art verwenden können, wurde diese Funktionalität auf eine
inkonsistente Art re-implementiert. BTW: Auf meine Nachfrage, was denn die
TECHNISCHE Begründung ist, das im KNX-Modul unterzubringen und damit anderen Modulen vorzuenthalten (https://forum.fhem.de/index.php?msg=1276876) bist Du leider nicht eingegangen... Das würde mich übrigens nach wie vor noch interessieren.
Kooperation kenne ich anders..
Aber immerhin hast Du offensichtlich mittlerweile eingesehen, dass initialized das falsche Kriterium für den scan ist (https://forum.fhem.de/index.php?msg=1276518)
Grüße,
würden wir in einer Firma zusammenarbeiten, würde ich folgendes vorschlagen:
Wir gehen zu dritt Mittagessen. Lockeres Gespräch, ein paar persönliche Interessen bereden. Dann gehen wir in einen Raum mit Whiteboards, Flipcharts. Wir reißen die aktuellen Struktur der Module auf und entwickeln ein paar Varianten.
Ich kann mir gut vorstellen, dass Ihr technisch auf Augenhöhe diskutiert und am Ende eine Lösung entsteht.
Geschriebene Kommunikation kann schnell falsch verstanden werden, weil der Ton (der die Musik macht) fehlt. Ich würde daher Sätze wie "Aber immerhin hast Du offensichtlich mittlerweile eingesehen" vermeiden.
Zitat von: GammaTwin am 01 Juli 2023, 10:07:35Geschriebene Kommunikation kann schnell falsch verstanden werden, weil der Ton (der die Musik macht) fehlt. Ich würde daher Sätze wie "Aber immerhin hast Du offensichtlich mittlerweile eingesehen" vermeiden.
Mag sein, dass der Ton nicht ganz gepasst hat.
Nur aus Neugierde: Welche Formulierung hättest denn
Du verwendet, wenn Du Dir (wie ich in diesem Thread (https://forum.fhem.de/index.php?topic=133667.msg1276518#msg1276518)) die Finger wund geschrieben hättest um zu begründen, dass INITIALIZED das falsche Kriterium ist und in der Folge dann die Zusammenarbeit des scan mit allem was nicht KNXIO ist komplett deaktiviert wird?
Zitat von: jw9 am 01 Juli 2023, 13:24:08Nur aus Neugierde: Welche Formulierung hättest denn Du verwendet
Ich muss gestehen, dass inhaltlich nicht folgen kann. Ich verstehe die Architektur der Module nicht.
Ich glaube verstanden zu haben, dass
- erwin sich etwas dabei gedacht hat und seine funktionierende Lösung in der cmd-ref entsprechend beschrieben hat.
- jw9 mit dieser Lösung einen Konflikt mit dem in Entwicklung befindlichen Modul hat
- jw9 in erwins Lösung einen "Architektur-Problem" sieht.
- erwin dieses Problem versteht
- erwin nach Veröffentlichung des Moduls von jw9 an einer gemeinsamen Lösung mitarbeiten würde
Wenn ich da völlig falsch liege, dann schon mal Entschuldigung.
Wenn Dir, jw9, aber vorerst nur die Aktualisierungsmöglichkeit des KNX_scan fehlt, hilft vielleicht mein Post #49 https://forum.fhem.de/index.php?msg=1194222 (https://forum.fhem.de/index.php?msg=1194222). Darin habe ich den Scan als DOIF konstruiert.
Vielleicht ein workaround bis zur Veröffentlichung. Und dann könnt Ihr nochmal Eure Sichtweisen besprechen.
Hi KNX community!
neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
Re.: KNX_scan
KNX_scan (als FHEM cmd) ist jetzt in einem neuen Modul: 98_KNX_scan.pm untergebracht. Das entspricht nun den Architekturvogaben und ist daher auch in der cmd-ref unter FHEM commands zu finden und auch "help KNX_scan" ist jetzt verfügbar.
Die KNX_scan() perl funktion ist wieder im KNX-Modul untergebracht.
Nicht unterstützt ist die useage falls als IO-Modul TUL bzw. KNXTUL verwendet wird, weil diese beiden Module in bestimmten Situationen falsche/irreführende Fehlermeldungen auslösen, bzw. falsche Resultate liefern. Siehe: https://forum.fhem.de/index.php?topic=133667.0 post #1 und #3. Danke übrigens fürs finden!
Ich akzeptiere, dass nicht alle user von TUL/KNXTUL auf KNXIO umsteigen (never change a running system), andererseits erwarte ich die Akzeptanz, das neue Funktionalitäten, in diesem Fall "Hilfsfunktionen/Utilities/Goodies", nicht von allen bisherigen Modulen unterstützt werden, wenn es damit Probleme gibt.
Dass ich die betroffenen Module nicht ändern darf (bin nicht der Owner) und will, ist hinlänglich dokumentiert. Aber evtl. findet sich jemand, der die Verantwortung/den Support dafür übernehmen will.
Das ich mit meiner vorigen Änderung "Module in development" von der Funktion ausschließe, war mir zu dem Zeitpunkt weder bekannt noch bewußt und wird hiermit korrigiert. Von der Progammlogik / Wartbarkeit wär's zwar im IO-Modul besser aufgehoben, (wird zu 99% von einem <io-device>:xxxxx event aufgerufen), aber was solls...
PS: Meine Interpretation der Begriffe: supported / unterstützt:
-supported: cmd bzw. funktion sollte funktionieren, falls nicht ist das ein bug und wird gefixt, falls nicht möglich - als Einschränkung in der cmd-ref dokumentiert.
-not supported: kann funktionieren, muss aber nicht (in allen Situationen korrekt) funktionieren ! Kein fix, evtl. gibts einen "hack" / workaround.
Diese Definition ist nicht auf meinem Mist gewachsen, sie stammt, frei übersetzt u. gekürzt, von einem zahlungspflichtigen SW-Service Vertrag.
Als absolutes NOGO empfinde ich support posts, die basierend auf nicht aktueller Version oder lokal modifizierten Modulen gemacht werden ohne im selben post darauf explizit hinzuweisen, (noch besser: die Modifikation/Version# zu posten), weil damit ein nachvollziehen des Problems unmöglich wird.
Etliche Rückfragen, "falsche Annahmen", Missverständnisse,... könnten vermieden werden, wenn man das [link]https://forum.fhem.de/index.php?topic=71806.0[/link] vor dem posten liest, und dadurch mit weniger Aufwand zu schnelleren/besseren Lösungen kommt.
l.g.erwin
Zitat von: erwin am 13 Juli 2023, 22:03:23Ich akzeptiere, dass nicht alle user von TUL/KNXTUL auf KNXIO umsteigen (never change a running system),
Wie ich schon mehrfach erläutert hatte geht es nicht um "never change ..." sondern vielmehr darum, dass die Funktionalität (direkte Anbindung an KNX mittels TPUART) mit KNXIO nicht geht.
Zitatandererseits erwarte ich die Akzeptanz, das neue Funktionalitäten, in diesem Fall "Hilfsfunktionen/Utilities/Goodies", nicht von allen bisherigen Modulen unterstützt werden, wenn es damit Probleme gibt.
Habe ich so auch nie erwartet.
Nach der Diskussion in diesem Thread (https://forum.fhem.de/index.php?topic=133667.0) hatte ich nicht den Eindruck, dass bei Dir die Bereitschaft gegeben ist, vom "INITIALIZED" als Kriterium abzurücken. Entsprechend hatte ich daraufhin einen eigenen scan implementiert.
Dann hattest Du den scan auf connect umgestellt, woraufhin ich meinen scan wieder ausgebaut hatte.
Nur um festzustellen, dass Du kurz darauf den scan verschoben und damit die Nutzung aus anderen Modulen heraus unterbunden hast.
Habe dann meinen scan wieder eingebaut und habe jetzt Ruhe. Der ist eh besser :-)
ZitatDass ich die betroffenen Module nicht ändern darf (bin nicht der Owner) und will,
Ist einsichtig. Hatte ich aber auch nie gefordert! Aktiv die Zusammenarbeit unterbinden ist aber auch nicht die feine englische Art, oder?
ZitatVon der Progammlogik / Wartbarkeit wär's zwar im IO-Modul besser aufgehoben, (wird zu 99% von einem <io-device>:xxxxx event aufgerufen), aber was solls...
Das kann man durchaus differenzierter betrachten. Aber ich will an dieser Stelle nicht ein weiteres Fass aufmachen...
ZitatPS: Meine Interpretation der Begriffe: supported / unterstützt:
-supported: cmd bzw. funktion sollte funktionieren, falls nicht ist das ein bug und wird gefixt, falls nicht möglich - als Einschränkung in der cmd-ref dokumentiert.
-not supported: kann funktionieren, muss aber nicht (in allen Situationen korrekt) funktionieren ! Kein fix, evtl. gibts einen "hack" / workaround.
Diese Definition ist nicht auf meinem Mist gewachsen, sie stammt, frei übersetzt u. gekürzt, von einem zahlungspflichtigen SW-Service Vertrag.
Nach dieser Definition hatte ich weder um einen Fix noch um eine Änderung der Doku gebeten. Schon gar nicht im TUL-Modul. Verstehe also Deine Aufregung nicht wirklich.
ZitatAls absolutes NOGO empfinde ich support posts, die basierend auf nicht aktueller Version oder lokal modifizierten Modulen gemacht werden ohne im selben post darauf explizit hinzuweisen,
Hmmm... Welchen "support post" meinst Du damit genau?
Es ging mir auch nie darum, support für das TUL-Modul zu erhalten. Lediglich darum, dass die Zusammenarbeit nicht
AKTIV unterbunden wird.
Hallo Erwin,
ich habe folgenden Fehlermeldungen, die ich früher nicht hatte:
2023.08.20 21:51:16 2: KNX_0005036 [KNX_encodeByDpt 1413]: gadName=g1 VALUE=Radio Wien - Sommer does not match allowed values: (?^msix:.{1,14})
2023.08.20 21:51:16 2: di_Display_Statustext2: set KNX_0005036 g1 Radio Wien - Sommer: "set KNX_0005036 g1 Radio Wien - Sommer" failed, see Log-Messages
Ist hier der String zu lange? Wie kann ich das lösen?
lg,
Matthias
Hi Matthias!
ich nehme an, das um einen dpt16.xxx geht,
und ja der string ist zu lang, hat 19 Zeichen, 14 sind das Maximum.
In diesem Bereich wurde schon lang nichts geändert...., in der nächsten Version werden UTF-8 (z.b. deutsche Sonderzeichen (ÄÜÖß...) besser unterstützt werden. Allerdings nur für dpt16.001, im ASCII gibts die nicht!
ZitatWie kann ich das lösen?
Wenn ich wüsste, wie der String entsteht, würde ich folgendes vorschlagen:
my $newstring = substr($string,0,14);
fhem("set KNX_0005036 g1 $newstring"); l.g. erwin
Hi Erwin,
also die Einträge tauchen bei mir in den Logs "fhem-2023-07.log" erst seit Juli auf und der Wert wird an den Bus nicht mehr übergeben. Das war bis jetzt aber immer der Fall.
Setzen tue ich den Wert mittels DOIF:
set KNX_0005036 g1 [CR_755_Radio] - [KNX_0104055]lg,
Matthias
Hi Matthias,
OK, das mit den Meldungen glaube ich dir ja, und geändert wurde in dem Bereich (ich hab bis April 2023 gecheckt) nichts, ausser dieser zusätzlichen Log-Msg!
Tatsache ist, dein string ist zu lang (19 Zeichen), im Standard definiert sind max. 14 Zeichen.
Nachdem ich selbst kein Text-display hab, hab ich mir ein Datenblatt von MDT geholt, da steht folgendes:
ZitatDer Glastaster II Smart mit Temperatursensor .... Weiterhin können benutzerdefinierte 1 Bit Meldungen und
14 Byte Texttelegramme angezeigt werden.
die Frage: welches display hast du?
Stand jetzt: falls ein set auf ein dpt16 kommt, länger als 14 Zeichen, wird es verworfen.- nix an den Bus gesendet!
Mögliche Lösungen:
1) du limitierst dein set... auf 14 Zeichen. - beim doif kann ich dir allerdings überhaupt nicht helfen...
2) ich könnte im Modul den Text ab dem 15. Zeichen abschneiden und den Rest an den bus senden
gefällt mir eigentlich gar nicht, verfälscht den Willen des Users, und eine Log msg müsste ich dennoch erzeugen...
l.g.erwin
Hallo Erwin,
ja, ich verwende genau diesen Glastastertyp und der String ist auf 14 Zeichen begrenzt.
Mein System ist schon sehr gewachsen und mit der großen Zahl der DOIFs auch schon recht unübersichtlich.
Ich bin daher immer dankbar, wenn etwas einfach funktioniert und ich nicht immer Zusatzfunktionen oder Userreading erstellen müßte. FHEM ist super flexibel aber auch leider manchmal nicht sehr userfreundlich. Das System soll mir das Leben doch erleichtern und mich nicht Stundenlang beschäftigen ;)
Ich verstehe natürlich auch Deine Philosphie, dass der Code nicht mehr als notwendig eingreifen sollte und der User wissen sollte was er tut.
Ich werde mir eventuell meine Myutil erweitern.
lg,
Matthias
Hi Matthias,
was ich nicht weiß: Wie verhält sich das Display, wenn mehr als 14 Zeichen ankommen? .. kommt irgendwas an, oder werden die ersten oder letzten 14 Zeichen angezeigt???
Um das testen zu können, wird es in der nächsten Version einen "dptRAW" geben, der beliebig lange hex-strings an das device schickt, bzw. auch empfängt und als reading darstellt.
um z.b den string 'abcdefghij' zu schicken, schreibt man:
set <device> <gadName> 006162636465666768696a00verfügbar vmtl. ab nächster Woche...
Abhängig von den Ergebnissen dieser Tests, werde ich mir überlegen Option 2 zu implementieren.
l.g.erwin
Hi Erwin,
bis jetzt wurden die Strings angezeigt und vom Display abgeschnitten. Das war auch ok für mich. Nur seit dem ich diese Fehlermeldung bekomme, wird nichts mehr geschickt und damit auch gar kein Update am Taster angezeigt.
Beim set Befehl geht natürlich auch nichts durch....
2023.08.24 14:43:32 1: PERL WARNING: Argument "" isn't numeric in subtraction (-) at /opt/fhem/FHEM/92_FileLog.pm line 942.
2023.08.24 14:43:46 2: KNX_0005036 [KNX_encodeByDpt 1413]: gadName=g1 VALUE=006162636465666768696a00 does not match allowed values: (?^msix:.{1,14})
2023.08.24 14:43:50 1: LOG: WPM set 52.
Damit kann ich das so nicht testen.
lg,
Matthias
Hi Matthias!
das kannst du auch NOCH NICHT testen, dazu brauchst du den dptRAW, den es erst ab nächster Woche gibt....
Zitatbis jetzt wurden die Strings angezeigt und vom Display abgeschnitten. Das war auch ok für mich.....
Ich habe mich entschlossen, den dpt16 so wie in OPT 2 beschrieben zu ändern, in der Version von nächster Woche.
Test läuft...
l.g. Erwin
Hi KNX_Community!
Neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
Viele changes bei dpt range,units, neue sub dpt's , ich habe ein "neues" dpt standard document (2021) gefunden, das bisherige war aus 2013!
NEU: dptRAW - erlaubt beliebige hex strings zu senden/empfangen, die KNX-Hardware muss das natürlich auswerten können! Beispiele: siehe cmdref . Ist gedacht für Entwickler von KNX-HW-devices....
@Matthias, du brauchst nicht testen, dpt16 sollte jetzt so funktionieren, es wird auf Länge 14char abgeschnitten + Log-msg.
@Amenophis86, der dpt251.600 ist jetzt unterstützt.
l.g.erwin
Guten Morgen,
Danke für die Änderungen.
Ich hätte noch eine Frage. Unterscheidet FHEM zwischen GroupValueWrite und GroupValueResponse oder wird bei beiden ein Event generiert? Ich tippe auf beide.
Hintergrund ist, dass ich aktuell mit Home Assistent ein bisschen teste. Hier werden die Daten regelmäßig abgefragt, was dazu führt, das FHEM mir Push Nachrichten schickt, obwohl der Status sich gar nicht gebändert hat. Dies kann ich aber auch mit event-on-change-reading nicht abfangen, da ich teilweise bei manchen Dingen bei jedem Trigger senden muss.
Da ich, wenn überhaupt, beide Systeme parallel betreiben werde, muss ich mir hier etwas überlegen und dazu will ich erstmal die Gründe verstehen :)
Hi Amenophis86,
ZitatUnterscheidet FHEM zwischen GroupValueWrite und GroupValueResponse oder wird bei beiden ein Event generiert?
Du meinst bei einer msg Richtung KNX-Bus->FHEM ? Nein, wird nicht unterschieden, beide werden in "getreading" kopiert. Event wird ausgelöst, abhängig von event-on-xxx.
Ein GroupValueRead Richtung KNX-Bus->FHEM wird über das Attr. putCmd gesteuert...
Ich verstehe nicht, warum HA regelmäßig den Bus abfragt, ist in einem KNX-system kontraproduktiv, sowas kann man mittels ETS-Parameter (z.b. intervall, Value change, Value threshold,...) in den meisten KNX devices festlegen.
Gutes Beispiel ist mein Windsensor: mittels ETS definiert:
1) sende Windspeed, min intervall 5 sekunden UND Wert Änderung > 5%.
2) sende Max/Min Windspeed jede Minute.
Update: einem GroupValueResponse geht immer ein GroupValueRead voraus, (wo immer der ausgelöst wird), FHEM kann das nicht unterscheiden ob selbst "verursacht" (mit get-cmd) oder von einem beliebigen anderen Bus-Teilnehmer. Im Endeffekt ist es gleichgültig, ob ein Write oder Response ankommt, es ist immer ein "status" vom device.
l.g.erwin
Hallo erwin,
HA scheint zu unterscheiden, ob ein Response oder Write vorliegt. Ein Response ist quasi kein neues Auslösen eines Events, sondern nur ein bestätigen des aktuellen Zustandes. Ein Write ist ein neues Event. Ich kann diese Logik nachvollziehen und frage mich, ob es nicht sinnvoll wäre auch in FHEM eine Unterscheidung herbei zuführen? Beispiel, wenn ich mit get abfrage, dann will ich auch nicht immer, dass das Event ausgelöst wird, sondern manchmal verpasst FHEM zB bei mir ein Event. Dies kann sein, weil ich den knxd deaktivieren muss, wenn ich eine neue PA vergebe oder FHEM für ein Update neustarten musste etc.
Warum HA die Zustände regelmäßig abfragt habe ich auch noch nicht ganz verstanden, aber vermutlich um sicherzustellen, dass kein Event verpasst wurde. Bei einer Unterscheidung zwischen Response und Write ist das ja auch nicht schlimm.
Mir ging es in erster Linie darum es zu verstehen und das habe ich nun. Jetzt muss ich überlegen, wie ich damit umgehe :)
Hi,
evtl. nomals zur Klärung:
in FHEM werden die entsprechenden readings IMMER mit jeder empfangenen msg upgedatet, der nachfolgende Event (gesteuert über die event-on-xx Attr's) hat nur den Sinn:
1) in der GUI die reading Zeile dynamisch upzudaten (und rot einfärben....)
2) FileLog / DbLog auszulösen.
3) notify/doif/... auszulösen.
4) evtl. auch noch andere Module auszulösen, die diese events subscribed haben... (e.g. MQTT)...
.. das ist jetzt überhaupt nicht KNX-spezifisch, das ist FHEM core Funktion.
FHEM-KNX spezifisch ist, das GroupValueWrite und GroupValueResponse beide im "get-reading" landen.
... Wobei ich beim Empfang einer GroupValueResponse message keine Möglichkeit habe festzustellen, wodurch diese ausgelöst wurde! (FHEM get-cmd oder v. anderem system GroupValueRead)
l.g.erwin
Wir reden glaube leicht aneinander vorbei :)
Mir ist sowohl klar, wie FHEM mit event-on... etc arbeitet als auch, wie KNX arbeitet. Die Frage, welche sich mir stellt ist, ob die Zusammenarbeit so 100% korrekt ist, wie es im Moment ist. Ich gebe dir ein einfaches Beispiel:
Ich öffne die ETS und frage den Zustand über eine GA mittels "Wert lesen" ab. Was ich bekomme ist ein GroupValueResponse und kein GroupValueWrite. Warum gibt es Unterschiede? Weil KNX klar sagt, ich kann auch den Zustand abfragen wollen ohne, dass andere Geräte darauf reagieren. Gleiches gibt es in FHEM, in dem ich mittels event-on-change und event-on-update arbeite. Problem ist, dass FHEM im Moment zwischen GroupValueWrite und GroupValueResponse nicht unterscheidet. Das heißt, wenn ich mittels ETS einen Zustand abfrage, dann wird bei FHEM automatisch ein Event getriggert.
Es stellt sich damit für mich die Frage, kann man an der Übergabestelle zwischen FHEM und KNX unterscheiden, welche Art von Antwort vom KNX BUS kommen? Wenn ja, dann könnte man vermutlich programmieren, dass ein GroupValueResponse standardmäßig kein Event triggert in FHEM, sondern ein Reading nur auf den aktuellen Stand bringt und ein GroupValueWrite das Reading auf den aktuellen Stand bringt und auch ein Event triggert. Das ist alles worum es mir geht :)
Hi,
Zitat...Weil KNX klar sagt, ich kann auch den Zustand abfragen wollen ohne, dass andere Geräte darauf reagieren
Ja das stimmt natürlich, allerdings ist FHEM kein KNX-Gerät, sondern (in KNX-Terminologie) ein Monitor, der grundsätzlich jede GA in irgendeiner Weise verarbeitet bzw. darstellt.
Dein ETS-Beispiel bezieht sich offensichtlich auf den ETS-Group-Monitor, der exakt gleich funktioniert wie FHEM. Alles was vom Bus kommt, wird dargestellt, unabhängig davon wer das ausgelöst hat.
ZitatWenn ja, dann könnte man vermutlich programmieren, dass ein GroupValueResponse standardmäßig kein Event triggert in FHEM, sondern ein Reading nur auf den aktuellen Stand bringt und ein GroupValueWrite das Reading auf den aktuellen Stand bringt und auch ein Event triggert....
.
Ja das könnte man, die Konsequenz wäre allerdings, das auch ein "fhem get ..." , (das ja ein GroupValueRead schickt und damit im Gerät ein GroupValueResponse auslöst), keinen EVENT auslösen würde.
Mir ist mom. nicht klar, wie ich das lösen könnte:
selbst wenn ich separate readings für GroupValueWrite und GroupValueResponse einführen würde, mit unterschiedlichen Handling der Events, würde das nichts an deinem Issue , bzw. an der Problematik von "fhem get ..." ändern.
Zitat...ich beim Empfang einer GroupValueResponse message keine Möglichkeit habe festzustellen, wodurch diese ausgelöst wurde! (FHEM get-cmd oder v. anderem system GroupValueRead)
Der Empang KNX-> FHEM läuft völlig asyncron!
PS: sehr, sehr "schräge Option": mittels eventMap/stateCmd auf <gadName> reagieren, nachschauen ob in den letzen x Sekunden ein "get <device> <gadName> von FHEM ausgelöst wurde. Falls JA-> event, falls NEIN->kein event.
... ungetestet weil noch nicht programmiert ... ;D
l.g. erwin
Ich mache mir auch nochmal Gedanken dazu. Wie gesagt ist es mir die Tage erst aufgefallen auf Grund der Home Assistent Thematik.
Hallo Erwin,
vielen Dank für die Änderung. Funktioniert super!
lg,
Matthias
Hi KNX_Community!
Neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
l.g. erwin
@ Amenophis86: du hast pm.
Hi KNX_Community!
Neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
l.g. erwin
Hi Erwin,
auch hier noch ein kurzer Beitrag von mir:
Habe gesehen, dass einige dpt´s aus der ETS nicht in FHEM konfiguriert werden können, z.B. gibt der "STEINEL True Presence Multisensor" den Luftdruck in Pa als dpt14.058 aus. Lässt sich das bei Gelegenheit noch ergänzen?
Danke jedenfalls!
LG
Stefan
Hi Stefan,
kein Problem, wird in der nächsten Version drin sein.
Inzwischen kann man sich damit behelfen: Wiki (https://wiki.fhem.de/wiki/KNX_Device_Definition_-_Beispiele#DPT_nicht_unterst%C3%BCtzt_im_KNX_Modul?)
l.g. erwin
Hi KNX_Community!
Neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
l.g. erwin
Hi Erwin,
danke! Werde ich testen.
Mit der alten Version habe ich heute noch folgende Fehlermeldung bekommen:
2023.12.28 07:08:29.022 3: Statustext5 [KNX_encodeByDpt 1528]: gadName= status modified by limits... Input= 05 Output= 05 Model= dpt16
Die Events dazu waren:
2023-12-28_07:08:29 Statustext5 last-sender: fhem
2023-12-28_07:08:29 Statustext5 status-set: 05
2023-12-28_07:08:29 Statustext5 05
Die Definition (von soeben) ist:
Internals:
DEF 9/0/7:dpt16:status
FUUID 6483aaa4-f33f-d238-a693-84de97d117188320
IODev KNXD
NAME Statustext5
NR 214
STATE HarmonyBuero a
TYPE KNX
eventCount 13978
model dpt16
GADDETAILS:
status:
CODE 09007
MODEL dpt16
NO 1
OPTION
RDNAMEGET status-get
RDNAMESET status-set
SETLIST :multiple,>CLR<
GADTABLE:
09007 status
READINGS:
2023-12-28 01:13:06 IODev KNXD
2023-12-28 10:28:40 last-sender fhem
2023-12-28 10:28:40 state HarmonyBuero a
2023-12-28 10:28:40 status-set HarmonyBuero a
Attributes:
group KNX
room KNX
Kann es sein, dass das bei einem Text (dpt16) kommt, wenn die Textnachricht rein numerisch ist (05)? Welche Aussage hat die Meldung?
LG
Stefan
Hi Erwin,
dpt14.058 wird akzeptiert jetzt, auch die dpt16-Meldung von oben ist weg in der neuen Version. Alles gut, danke!
LG
Stefan
Hallo,
ich habe mit dem Datentyp dpt14 meine Probleme: ich kann keine Negative Zahl schreiben.
im Log bekomme ich folgende Meldung:
<device> [KNX_limit 1476]: cmd value modified by limits... Input= -2 Output= -1.4e-45 Model= dpt14
Ursache ist die Definition von MIN=>-1.4e-45: das ist -0.00000000...001.
Praktisch ist also jede negative Zahl zu klein (kleiner als -0,000...0001).
Müsste es nicht eher MIN=>-1.7e38 lauten?
Ich verwende das originale 10_KNX.pm:
# $Id: 10_KNX.pm 28207 2023-11-25 18:06:19Z erwin $
Beste Grüße,
Gero
Hi Gero,
du hast recht, dein Vorschlag ist korrekt!
Ich muss noch ein paar andere Modifikationen testen, fix ab morgen im SVN!
l.g. & danke erwin
Hi KNX_Community!
Neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
l.g. erwin
Hi KNX-Community!
Neue Version ist am SVN, change-history (wie immer...) im 1.Beitrag in diesem Thread!
l.g. erwin