Wenn ich ein Device will, mit dem ich Werte setzen kann, das aber auch eingehende Werte empfängt, jedoch NICHT auf Anfragen antwortet, nehme ich SET, oder?
Bei
6/2/1:dpt9.001:desiredTemp:set:nosuffix
wird jedoch nicht das Reading desiredTemp, sondern das Reading "", also leer oder irgendein whitespace aktualisiert.
Wenn ich SET entferne, funktioniert es, bei einer Get Anfrage von einem KNX Aktor oder aus der ETS heraus antworten jedoch 2 Geräte, nämlich FHEM und eben der Heizungsaktor. Nur letzterer soll antworten!
sG
Joe
...und wie immer meine erste Frage: Kannst Du bitte noch das Level-5-Log anhängen?
Ist schwer im Flugzeug am Handy....
Auf
set DEVICE desiredTemp 29
bekomme ich dieses Log. Es wird also ein leeres Reading mit dem Wert "29.00 °C" angelegt.
Eventmonitor-Auszug
KNX DEVICE desiredTemp: 29.00 °C
KNX DEVICE Soll: 31.0° Ist: 21.8° Ventil: 0 % Return: 0.0°
KNX DEVICE : 29.00 °C
KNX DEVICE last-sender: 1/1/93
KNX DEVICE Soll: 31.0° Ist: 21.8° Ventil: 0 % Return: 0.0°
KNX DEVICE : 29.00 °C
KNX DEVICE last-sender: 1/1/93
KNX DEVICE Soll: 31.0° Ist: 21.8° Ventil: 0 % Return: 0.0°
Anbei ein Screenshot dazu.
Für dieses leere Reading wird übrigens kein Event aktualisiert,
Hier das Log5.
Ist es korrekt, dass der Status hier 3x ausgewertet wird?
2018.00.00 06:50:08 5: enter set knx.DEVICE: hash: HASH(0x5648f83889a0), attributes: knx.DEVICE, desiredTemp, 29 |
2018.00.00 06:50:08 5: set knx.DEVICE: desired target is gad desiredTemp, command: 29, args: |
2018.00.00 06:50:08 5: check value: 29, gadName: desiredTemp |
2018.00.00 06:50:08 5: check value: 29, gadName: desiredTemp, model: dpt9.001, pattern: (?^i:[-+]?(?:\d*[\.\,])?\d+) |
2018.00.00 06:50:08 5: encode value: 29, gadName: desiredTemp |
2018.00.00 06:50:08 5: encode model: dpt9.001, code: dpt9, value: 29 |
2018.00.00 06:50:08 5: limit: DIR: ENCODE FACTOR: 1 OFFSET: 1 MIN: 1 MAX: 1 |
2018.00.00 06:50:08 5: encode model: dpt9.001, code: dpt9, value: 29, numval: 3498, hexval: 000daa |
2018.00.00 06:50:08 5: set knx.DEVICE: cmd: 29, value: 29, translated: 000daa |
2018.00.00 06:50:08 5: decode value: 000daa, gadName: desiredTemp |
2018.00.00 06:50:08 5: decode model: dpt9.001, code: dpt9, value: 000daa |
2018.00.00 06:50:08 5: limit: DIR: DECODE FACTOR: 1 OFFSET: 1 MIN: 1 MAX: 1 |
2018.00.00 06:50:08 5: decode model: dpt9.001, code: dpt9, value: 000daa, numval: 29, state: 29.00 °C
2018.00.00 06:50:08 5: Enter eval...name: knx.DEVICE, gadName: desiredTemp, evalString:
{sprintf( |
"Soll: %4.1f° ".
"Ist: %4.1f° ". |
"Ventil: %3d %% ".
"Return: %4.1f°", |
ReadingsNum($name,"desired-temp",""), |
ReadingsNum($name,"measured-temp",""),
ReadingsNum($name,"ventil",""), |
ReadingsNum($name,"return-temp",""),
)}
2018.00.00 06:50:08 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 226592) line 1.
2018.00.00 06:50:08 5: Exit eval...result: Soll: 31.0° Ist: 21.8° Ventil: 0 % Return: 0.0°
2018.00.00 06:50:08 5: set name: knx.DEVICE - state replaced via command, result: state:Soll: 31.0° Ist: 21.8° Ventil:
0 % Return: 0.0°
2018.00.00 06:50:08 5: exit set
2018.00.00 06:50:08 5: parse: process message, device-name: knx.DEVICE, rd-name: desiredTemp, gadCode: 01225, model: dpt9
.001
2018.00.00 06:50:08 5: decode value: 0daa, gadName: desiredTemp
2018.00.00 06:50:08 5: decode model: dpt9.001, code: dpt9, value: 0daa
2018.00.00 06:50:08 5: limit: DIR: DECODE FACTOR: 1 OFFSET: 1 MIN: 1 MAX: 1
2018.00.00 06:50:08 5: decode model: dpt9.001, code: dpt9, value: 0daa, numval: 29, state: 29.00 °C
2018.00.00 06:50:08 5: received hash (wpi): HASH(0x5648f83889a0) name: knx.DEVICE, STATE: 29.00 °C, READING: desiredT
emp, SENDER: 0115d
2018.00.00 06:50:08 5: Enter eval...name: knx.DEVICE, gadName: desiredTemp, evalString:
{sprintf(
"Soll: %4.1f° ".
"Ist: %4.1f° ".
"Ventil: %3d %% ".
"Return: %4.1f°",
ReadingsNum($name,"desired-temp",""),
ReadingsNum($name,"measured-temp",""),
ReadingsNum($name,"ventil",""),
ReadingsNum($name,"return-temp",""),
)}
2018.00.00 06:50:08 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 226595) line 1.
2018.00.00 06:50:08 5: Exit eval...result: Soll: 31.0° Ist: 21.8° Ventil: 0 % Return: 0.0°
2018.00.00 06:50:08 5: parse device hash (wpi): HASH(0x5648f83889a0) name: knx.DEVICE - state replaced via command {sprin
tf(
"Soll: %4.1f° ".
"Ist: %4.1f° ".
"Ventil: %3d %% ".
"Return: %4.1f°",
ReadingsNum($name,"desired-temp",""),
ReadingsNum($name,"measured-temp",""),
ReadingsNum($name,"ventil",""),
ReadingsNum($name,"return-temp",""),
)} - state: Soll: 31.0° Ist: 21.8° Ventil: 0 % Return: 0.0°
2018.00.00 06:50:08 5: parse: process message, device-name: knx.DEVICE, rd-name: desiredTemp, gadCode: 01225, model: dpt9
.001
2018.00.00 06:50:08 5: decode value: 0daa, gadName: desiredTemp
2018.00.00 06:50:08 5: decode model: dpt9.001, code: dpt9, value: 0daa
2018.00.00 06:50:08 5: limit: DIR: DECODE FACTOR: 1 OFFSET: 1 MIN: 1 MAX: 1
2018.00.00 06:50:08 5: decode model: dpt9.001, code: dpt9, value: 0daa, numval: 29, state: 29.00 °C
2018.00.00 06:50:08 5: received hash (wpi): HASH(0x5648f83889a0) name: knx.DEVICE, STATE: 29.00 °C, READING: desiredT
emp, SENDER: 0115d
2018.00.00 06:50:08 5: Enter eval...name: knx.DEVICE, gadName: desiredTemp, evalString:
{sprintf(
"Soll: %4.1f° ".
"Ist: %4.1f° ".
"Ventil: %3d %% ".
"Return: %4.1f°",
ReadingsNum($name,"desired-temp",""),
ReadingsNum($name,"measured-temp",""),
ReadingsNum($name,"ventil",""),
ReadingsNum($name,"return-temp",""),
)}
2018.00.00 06:50:08 1: PERL WARNING: Argument "" isn't numeric in sprintf at (eval 226596) line 1.
2018.00.00 06:50:08 5: Exit eval...result: Soll: 31.0° Ist: 21.8° Ventil: 0 % Return: 0.0°
2018.00.00 06:50:08 5: parse device hash (wpi): HASH(0x5648f83889a0) name: knx.DEVICE - state replaced via command {sprin
tf(
"Soll: %4.1f° ".
"Ist: %4.1f° ".
"Ventil: %3d %% ".
"Return: %4.1f°",
ReadingsNum($name,"desired-temp",""),
ReadingsNum($name,"measured-temp",""),
ReadingsNum($name,"ventil",""),
ReadingsNum($name,"return-temp",""),
)} - state: Soll: 31.0° Ist: 21.8° Ventil: 0 % Return: 0.0°
sG Joe
Ich kann Dir noch nicht ganz folgen. Im Eingangspost schriebst Du, der Fehler ist, dass FHEM auf eine Leseanfrage antwortet.
Jetzt schickst Du aber ein Log vom "set".
Versuchst Du zwei Situationen zu beschreiben?
Richtig ist Deine Annahme, dass das gesendete Telegram direkt wieder empfangen wird und dieses Echo entsprechend ausgewertet wird. Das ist abhängig von der verwendeten Busanbindung - hier gibt es Unterschiede zwischen den physikalischen Adaptern.
Warum die Schleife bei Dir zwei mal durchlaufen wird, kann ich Dir aktuell noch nicht sagen...
Zitat von: Andi291 am 28 August 2018, 17:59:29
Ich kann Dir noch nicht ganz folgen. Im Eingangspost schriebst Du, der Fehler ist, dass FHEM auf eine Leseanfrage antwortet.
Jetzt schickst Du aber ein Log vom "set".
Ich schrieb, dass ich verhindern will, dass ein Device auf eine Leseanfrage antwortet. Darum möchte ich die Option SET nutzen,
da ich aus der Beschreibung heraus vermute, dass diese dafür gedacht und geeignet ist. (Stimmt das?)
Darum schicke ich auch ein Log vom "Set".
Jedoch verhaltet sich das Device mit eben dieser Option seltsam.
Es erzeugt eben Readings, die es meiner Meinung nach nicht erzeugen sollte.
Siehe Zeile:
KNX DEVICE : 29.00 °CHier wird ein Reading mit leerem Namen erzeugtm das den Wert 29 erhält.
sG
Joe
Punkt 1:
Implementiert ist folgendes:
Set: kann empfangen, kann antworten, kann "set", kann nicht "get"
Get: kann empfangen, kann antworten, kann "get", kann nicht "set"
Listenonly: kann empfangen, kann nicht antworten, kann nicht "get", kann nicht "set"
Schreibe ich bei Gelegenheit so in die Doku.
Wenn Du keine Antwort vom Device haben willst, muss putCmd für dieses Reading "undef" sein.
Punkt 2:
Das "leere" Reading kann ich nicht nachvollziehen. Steht im u.g. Log nicht drin und einen Reim drauf machen kann ich mir auch nicht...
Allgemein:
Dennoch eine Bitte (schon wieder :-)): Ein Problem --> eine Beschreibung --> Ein Trace --> Ein Thread.
Mit mehreren Beanstandungen in einem Block kann ich persönlich nicht umgehen. Und Punkten ohne Log kann ich nicht sinnvoll nachgehen.
Hallo Andi,
Punkt1:
danke für die Erläuterung. Werde putCmd mit "undef" umsetzen, bzw. für mich sogar zum Standard machen!
Punkt2:
Es geht mir tatsächlich darum, dass hier set nicht funktioniert!
Erstelle dieses Testdevice und sende ihm per ETS oder sonst irgendwie einen Temperaturwert.
defmod knx.Test.set KNX 0/0/9:dpt9.001:desiredTemp:set:nosuffix
attr knx.Test.set IODev KNX
attr knx.Test.set verbose 5
List VOR dem senden über ETS
list knx.Test.set
Internals:
CFGFN
DEF 0/0/9:dpt9.001:desiredTemp:set:nosuffix
DEVNAME knx.Test.set
FIRSTGADNAME desiredTemp
GETSTRING desiredTemp:noArg
IODev KNX
KNX_MSGCNT 1
KNX_RAWMSG C011ffw000090d78
KNX_TIME 2018-08-29 16:30:50
LASTInputDev KNX
MSGCNT 1
NAME knx.Test.set
NR 3786
NTFY_ORDER 50-knx.Test.set
SETSTRING desiredTemp:slider,-670760,13415,670760
STATE 28.00 °C
TYPE KNX
GADDETAILS:
desiredTemp:
CODE 00009
GROUP 0/0/9
MODEL dpt9.001
NO 1
OPTION set
RDNAMEGET
RDNAMEPUT
RDNAMESET desiredTemp
SETLIST :slider,-670760,13415,670760
GADTABLE:
00009 desiredTemp
OLDREADINGS:
READINGS:
Attributes:
IODev KNX
verbose 5
Log5 während dem Senden
2018.08.29 16:35:56 5: parse: process message, device-name: knx.Test.set, rd-name: desiredTemp, gadCode: 00009, model: dpt9.001
2018.08.29 16:35:56 5: decode value: 0daa, gadName: desiredTemp
2018.08.29 16:35:56 5: decode model: dpt9.001, code: dpt9, value: 0daa
2018.08.29 16:35:56 5: limit: DIR: DECODE FACTOR: 1 OFFSET: 1 MIN: 1 MAX: 1
2018.08.29 16:35:56 5: decode model: dpt9.001, code: dpt9, value: 0daa, numval: 29, state: 29.00 °C
2018.08.29 16:35:56 5: received hash (wpi): HASH(0x563c5f90e238) name: knx.Test.set, STATE: 29.00 °C, READING: desiredTemp, SENDER: 011ff
List NACH dem Senden über ETS
list knx.Test.set
Internals:
CFGFN
DEF 0/0/9:dpt9.001:desiredTemp:set:nosuffix
DEVNAME knx.Test.set
FIRSTGADNAME desiredTemp
GETSTRING desiredTemp:noArg
IODev KNX
KNX_MSGCNT 2
KNX_RAWMSG C011ffw000090daa
KNX_TIME 2018-08-29 16:35:56
LASTInputDev KNX
MSGCNT 2
NAME knx.Test.set
NR 3786
NTFY_ORDER 50-knx.Test.set
SETSTRING desiredTemp:slider,-670760,13415,670760
STATE 29.00 °C
TYPE KNX
GADDETAILS:
desiredTemp:
CODE 00009
GROUP 0/0/9
MODEL dpt9.001
NO 1
OPTION set
RDNAMEGET
RDNAMEPUT
RDNAMESET desiredTemp
SETLIST :slider,-670760,13415,670760
GADTABLE:
00009 desiredTemp
OLDREADINGS:
READINGS:
2018-08-29 16:35:56 29.00 °C
2018-08-29 16:35:56 last-sender 1/1/255
2018-08-29 16:35:56 state 29.00 °C
Attributes:
DbLogExclude .*
IODev KNX
verbose 5
Beachte das leere Reading mit dem Wert 29.00.
Anbei auch noch als Screenshot.
Ich hab das mit dem leeren Reading schon verstanden :-)
Dennoch sprechen die Logs eine andere Sprache...
Wurscht - Ich habs nachgestellt - kann ich nicht nachvollziehen. Bei mir wird kein leeres Reading angezeigt. Hast Du mit einem "HelloWorld"-Device gestartet oder gleich All-In?
Bei den Logs gebe ich dir recht.
Der Eventmonitorausschnitt aus meinem 2. Post zeigt es jedoch.
Getestet habe ich schon mit einem größeren Device mit über 10 GADs,
jedoch kann ich es auch definitiv nachstellen mit diesem kleinen Testdevice und einer GAD, die nur für den test verwendet wird.
Meine FHEm installation ist relativ frisch, EIB war nie im Einsatz, immer nur das KNX-Modul.
Auch hier war von anfang an diese neue Testversion im Einsatz, die alte KNX-Version ohne die PUT-Variante kam nie zum Einsatz.
Angebunden ist das TUL-Device über knxd auf einen Gira Router. Also alles ziemlich Standard.
sG Joe
Zur Info:
Hier ist ein ähnliches Problem beim Device "Dummy" gerade gefixt worden.
https://forum.fhem.de/index.php/topic,97576
Grüße,
ich habe den gleichen Fall als Thema angelegt.
https://forum.fhem.de/index.php/topic,99801.0.html (https://forum.fhem.de/index.php/topic,99801.0.html)