[eingechecked, thread closed] Neues major release zum Test

Begonnen von Andi291, 14 April 2018, 00:23:42

Vorheriges Thema - Nächstes Thema

JoeALLb

Ergänzung:
Bei diesem Device habe ich einen Anzeigefehler, wenn ich auf "set <device> umluft" um webfrontend gehe:

defmod knx.TEST2 KNX 8/6/240:dpt5:szene:nosuffix\
\
8/6/241:dpt1:umluft-position:nosuffix\
8/6/242:dpt1:umluft-stop:nosuffix\
8/6/243:dpt5.001:umluft-position:nosuffix\
8/6/244:dpt5.001:umluft-position-state:nosuffix\
8/6/245:dpt1.001:umluft-bewegung:nosuffix
attr knx.TEST2 IODev KNX
attr knx.TEST2 eventMap /abluft-langzeit 100:abluft oeffnen/abluft-langzeit 0:abluft schliessen/\
szene 1:szene standby/\
szene 2:szene abluft/\
szene 3:szene umluft/\
szene 4:szene open/
attr knx.TEST2 room 5-Todo
attr knx.TEST2 stateFormat umluft-position-state abluft-position-state
attr knx.TEST2 webCmd umluft
attr knx.TEST2 widgetOverride widgetOverride:textField-long\
eventMap:textField-long\
umluft:uzsuSelectRadio,oeffnen,schliessen\
szene:uzsuSelectRadio,standby,abluft,umluft,open

setstate knx.TEST2 40 % abluft-position-state
setstate knx.TEST2 2018-04-23 12:20:06 last-sender 1/1/102
setstate knx.TEST2 2018-04-23 12:20:06 state off
setstate knx.TEST2 2018-04-23 12:20:06 umluft-bewegung off
setstate knx.TEST2 2018-04-23 12:20:06 umluft-position-state 40 %
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Andi291

Joe, vielen Dank auf für's Testen...

Ich wird spätestens Himmelfahrt bei mir noch einen Batzen umstellen - dann haben wir auch einen "Migrationsleitfaden".

Melde mich, wenn eingechecked :-)

P.S.: Deinen Fehler schau ich mir noch an...

JoeALLb

#17
Puh, zu früh gefreut? Da immer ein Rückgabewert vorhanden war, ist es mir bisher nicht aufgefallen.
Scheinbar wird hier putCmd nicht mehr aufgerufen?

Wenn ich in der ETS eine Abfrage an die GAD 0/3/19 mache, bekomme ich als Rückgabewert 2.56°.
Woher nimmt er diese? Im Status stehen sie nicht, in putCmd steht zum Debug schlicht  {$value=16;},
das wird aber laut diesem Log gar nicht erst ausgeführt?!?
Wenn ich den Parameter ":nosuffix" weglasse, wird auch schön das Reading "return-temp-get 2.56 &deg;C" angelegt,
also sollte es an "nosuffix" auch nicht liegen.

2018.04.24 10:40:41 5: parse: process message, device-name: deviice, rd-name: return-temp, gadCode: 00313, model: dpt9.001
2018.04.24 10:40:41 5: received hash (r): HASH(0x563ea59c32b8) name: deviice, GET
2018.04.24 10:40:41 5: parse: process message, device-name: deviice, rd-name: return-temp, gadCode: 00313, model: dpt9.001
2018.04.24 10:40:41 5: decode value: 0100, gadName: return-temp
2018.04.24 10:40:41 5: decode model: dpt9.001, code: dpt9, value: 0100
2018.04.24 10:40:41 5: decode model: dpt9.001, code: dpt9, value: 0100, numval: 2.56, state: 2.56 &deg;C
2018.04.24 10:40:41 5: received hash (wpi): HASH(0x563ea59c32b8) name: deviice, STATE: 2.56 &deg;C, READING: return-temp, SENDER: 01101
2018.04.24 10:40:41 5: parse device hash (wpi): HASH(0x563ea59c32b8) name: deviice - state replaced via command {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",""),
)} - state: Soll: 13.0° Ist: 15.6° Ventil:   0 % Return:  2.6°


Hast Du dazu eine Idee?
Ich überlege gerade, auf welche Version ich zurückwechseln sollte, denn das bringt meine Heizungssteuerung durcheinander.
Übrigens habe ich auch geprüft, ob ich die GAD v ersehentlich 2x angelegt habe, was jedoch nicht zutrifft
cat fhem.cfg |grep "0/3/19[^0-9]"
0/3/19:dpt9.001:return-temp:nosuffix\



sG
Joe
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Andi291

Puh, so weit ich auf die Schnelle sehe, wird der Wert 0x100 = 2,56°C vom Bus empfangen.
Klemm mal FHEM ab und frag nochmal - ich möchte meinen, hier antwortet ein anderes Gerät...

JoeALLb

Wenn ich mich n fhem dem Device eine andere Gad gebe, antwortet in der ETS nichts mehr, daher sollte die Antwort schon von fhem kommen!

Joe
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Andi291

Aaaaalso....

Ich vermute:
- Zeile 1288: dein Umfangreiches StateCmd evaluiert letztendlich zu 2,6°C
- putCmd 16(dezimal) = 0x100 = 2,6°C (gerundet), sagt zumindest die ETS
- Zeile 1244: value und orgValue sind gleich, deshalb wird nicht gelogged

Probiere:
- StateCmd abschalten oder mit einer kleinen Konstante befüllen
- PutCmd mit 1CD5 befüllen

Damit dürftest Du 99°C aus putCmd erhalten. Wenn der Wert deutlich kleiner ist, war es ggf. doch stateCmd, dann geht es weiter.


JoeALLb

#21
Aaaalso
#1 ist es nicht.
#2 weiß ich nicht.
#3 vermutlich, da die Heizung aus ist ändert sich die Temperatur nicht oft.

Aber:
Dies funktioniert nicht und liefert den falschen Wert!
$value= ReadingsNum("tempSensor","temperature",0,1)

Das funktioniert und liefert 15,25°.
$value= ReadingsNum("tempSensor","temperature",0,1) + 0.01

Nun sollte ReadingsNum doch definitig eine Zahl zurückliefern?!?!!
Auch der Verzicht auf die Rundung durch oder das Runden auf 0 Nachkommastellen brachte keine Besserung.
Der Defaultwert "0" schlägt ebenfalls nicht zu, ein ündern bringt nichts.
Ich bleibe also im Moment bei der Schreibweise + 0.01. Bin mir aber sicher, dass das schon mal funktioniert hat!

Edit1:
Was ich festgestellt habe ist, dass ich aktuell 4 Antworten in der ETS bekomme! die erste von 0.0.0 ohne wert, danach 3x von 1.1.253 (knxd) den Wert "15,25°".
Anbei ein Screenshot dazu

Edit2:
Ein entfernen von :nosuffix erhöht die Antworten von 3x auf 4x, auch bei entferntem putCmd. putCmd sollte demnach auch nicht daran "schuld" sein.

sG Joe
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

JoeALLb

Anbei noch ein Patch für Szenen dpt17.001.

DPT5 könnte ja auch genommen werden, ist aber immer um 1 zu niedrig.

Ob das die richtige bzw. Eleganteste Methode ist, kann ich leide rnicht sagen.
in der ETS kommt das richtige an, de rumgekehrte Weg geht leider nicht. Etwas in der ETS gesetztes kommt in FHEM nicht an.
Auch nach dem "set device szene 4" steht das reading des Devices nicht auf 4.

Dennoch, für mich nutze ich es mal, da das ständige umrechnen der szenen mit +1 für verwirrung sorgte ;-)



diff /mnt/SeaCloud/10_KNX.pm FHEM/10_KNX.pm
189a190,192
>
> #Szenen
>       "dpt17.001"              => {CODE=>"dpt17", UNIT=>"", FACTOR=>1, OFFSET=>1, PATTERN=>qr/[+-]?\d{1,5}/i, MIN=>0, MAX=>255},
1633c1636,1642
<       }
---
>       }
>       #Szenen
>         elsif ($code eq "dpt17")
>         {
>                 $numval = $value;
>                 $hexval = sprintf("00%.2x",($numval));
>         }
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

JoeALLb

Edit3:
Also das mit "+ 0.01" hatte im test die Auswirkung, dass statt 3, 4 Telegramme auf den Bus gescgickt wurden, von daher wurde scheinbar dadurch dann ein anderes Ergebnis angezeigt.
der erste gesendete Wert hatte noch immer die 2,56°, die anderen die korrekte Temperatur. Der Sender war bei allen Telegrammen der KNXD.

Hilft das weiter?

sG
Joe
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Andi291

Nein, tut es nicht.

Nochmal:

Hast Du stateCmd mal weegelöscht oder durch eine Konstante ersetzt? Was passiert dann?
Hast Du in putCmd eine andere Konstante reingeschrieben? Dann dürfte ein anderer Wert gesendet werden...

Wenn ich recht habe, wird wieder gelogged...

JoeALLb

#25
Hier ein Screenshot mit gemachten Tests.

Was mich besonders wundert:
1. ich bekomme 4-6 Antworten auf dem Bus bei einer Anfrage aus der ETS heraus. (ist das ein Fehler im Modul?)
2. besonders Test 6: Bei konstantem putCmd sollte keine andere Antwort geliefert werden, oder?
Hier wird 5x die Konstante und danach 1x ein anderer Wert geschickt.
3. bei Prüfung 4: putCmd ist nicht vorhanden, stateCMD auf Konstant 20. Diese wurde auch schon aktualisiert! Dennoch gibt eine Leseanfrage auf das Device welches 18,81 als Wert an ETS zurück liefert. Kommt der Wert aus einer internen, noch alten Variable?

Was ich geprüft habe:
1. Wenn ich in FHEM diese eine GAD ändere, bekomme ich in der ETS keine Antworten. Es antwortet also kein anderes Device!


Logs reiche ich noch nach.

Edit: Hier die Logs zu 2 Fällen: Sehen eigentlich ganz ok aus bis auf die Mehrfachausführung
Log1 putCmd = {$value=21}:
5: parse: process message, device-name: HeizungKeller.1.1.1_A, rd-name: return-temp, gadCode: 00313, model: dpt9.001
5: received hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET
5: encode value: 21, gadName: return-temp
5: encode model: dpt9.001, code: dpt9, value: 21
5: encode normalized value: 21
5: encode model: dpt9.001, code: dpt9, value: 21, numval: 3098, hexval: 000c1a
5: received, send answer hash: HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET: 000c1a, READING: return-temp
5: parse: process message, device-name: HeizungKeller.1.1.1_A, rd-name: return-temp, gadCode: 00313, model: dpt9.001
5: received hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET
5: encode value: 21, gadName: return-temp
5: encode model: dpt9.001, code: dpt9, value: 21
5: encode normalized value: 21
5: encode model: dpt9.001, code: dpt9, value: 21, numval: 3098, hexval: 000c1a
5: received, send answer hash: HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET: 000c1a, READING: return-temp
5: parse: process message, device-name: HeizungKeller.1.1.1_A, rd-name: return-temp, gadCode: 00313, model: dpt9.001
5: received hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET
5: encode value: 21, gadName: return-temp
5: encode model: dpt9.001, code: dpt9, value: 21
5: encode normalized value: 21
5: encode model: dpt9.001, code: dpt9, value: 21, numval: 3098, hexval: 000c1a
5: received, send answer hash: HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET: 000c1a, READING: return-temp
5: parse: process message, device-name: HeizungKeller.1.1.1_A, rd-name: return-temp, gadCode: 00313, model: dpt9.001
5: received hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET
5: encode value: 21, gadName: return-temp
5: encode model: dpt9.001, code: dpt9, value: 21
5: encode normalized value: 21
5: encode model: dpt9.001, code: dpt9, value: 21, numval: 3098, hexval: 000c1a
5: received, send answer hash: HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET: 000c1a, READING: return-temp
5: parse: process message, device-name: HeizungKeller.1.1.1_A, rd-name: return-temp, gadCode: 00313, model: dpt9.001
5: received hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET
5: encode value: 21, gadName: return-temp
5: encode model: dpt9.001, code: dpt9, value: 21
5: encode normalized value: 21
5: encode model: dpt9.001, code: dpt9, value: 21, numval: 3098, hexval: 000c1a
5: received, send answer hash: HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET: 000c1a, READING: return-temp


Log 2: putCmd= {$value= int(rand(10))}
5: parse: process message, device-name: HeizungKeller.1.1.1_A, rd-name: return-temp, gadCode: 00313, model: dpt9.001
5: received hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET
5: parse device hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A - put replaced via command {$value= int(rand(10))} - value: 0
5: encode value: 0, gadName: return-temp
5: encode model: dpt9.001, code: dpt9, value: 0
5: encode normalized value: 0
5: encode model: dpt9.001, code: dpt9, value: 0, numval: 0, hexval: 000000
5: received, send answer hash: HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET: 000000, READING: return-temp
5: parse: process message, device-name: HeizungKeller.1.1.1_A, rd-name: return-temp, gadCode: 00313, model: dpt9.001
5: received hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET
5: parse device hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A - put replaced via command {$value= int(rand(10))} - value: 1
5: encode value: 1, gadName: return-temp
5: encode model: dpt9.001, code: dpt9, value: 1
5: encode normalized value: 1
5: encode model: dpt9.001, code: dpt9, value: 1, numval: 100, hexval: 000064
5: received, send answer hash: HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET: 000064, READING: return-temp
5: parse: process message, device-name: HeizungKeller.1.1.1_A, rd-name: return-temp, gadCode: 00313, model: dpt9.001
5: received hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET
5: parse device hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A - put replaced via command {$value= int(rand(10))} - value: 9
5: encode value: 9, gadName: return-temp
5: encode model: dpt9.001, code: dpt9, value: 9
5: encode normalized value: 9
5: encode model: dpt9.001, code: dpt9, value: 9, numval: 900, hexval: 000384
5: received, send answer hash: HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET: 000384, READING: return-temp
5: parse: process message, device-name: HeizungKeller.1.1.1_A, rd-name: return-temp, gadCode: 00313, model: dpt9.001
5: received hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET
5: encode value: 9, gadName: return-temp
5: encode model: dpt9.001, code: dpt9, value: 9
5: encode normalized value: 9
5: encode model: dpt9.001, code: dpt9, value: 9, numval: 900, hexval: 000384
5: received, send answer hash: HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET: 000384, READING: return-temp
5: parse: process message, device-name: HeizungKeller.1.1.1_A, rd-name: return-temp, gadCode: 00313, model: dpt9.001
5: received hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET
5: parse device hash (r): HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A - put replaced via command {$value= int(rand(10))} - value: 3
5: encode value: 3, gadName: return-temp
5: encode model: dpt9.001, code: dpt9, value: 3
5: encode normalized value: 3
5: encode model: dpt9.001, code: dpt9, value: 3, numval: 300, hexval: 00012c
5: received, send answer hash: HASH(0x563ea59c32b8) name: HeizungKeller.1.1.1_A, GET: 00012c, READING: return-temp
5: parse: process message, device-name: knx.quad8.temp2, rd-name: temperature, gadCode: 01015, model: dpt9.001
5: decode value: 0cb0, gadName: temperature
5: decode model: dpt9.001, code: dpt9, value: 0cb0
5: decode model: dpt9.001, code: dpt9, value: 0cb0, numval: 24, state: 24.00 &deg;C
5: received hash (wpi): HASH(0x563ea588c060) name: knx.quad8.temp2, STATE: 24.00 &deg;C, READING: temperature, SENDER: 01103
5: parse: process message, device-name: knx.quad8.temp2, rd-name: temperature, gadCode: 01015, model: dpt9.001
5: decode value: 0cb0, gadName: temperature
5: decode model: dpt9.001, code: dpt9, value: 0cb0
5: decode model: dpt9.001, code: dpt9, value: 0cb0, numval: 24, state: 24.00 &deg;C
5: received hash (wpi): HASH(0x563ea588c060) name: knx.quad8.temp2, STATE: 24.00 &deg;C, READING: temperature, SENDER: 01103
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Andi291

So...

Ich lade nochmal einen kleinen Patch hoch. Es gab noch ein Problem bei nicht gesetztem putString.

Ansonsten kann ich bis auf die Rundungsfehler Deine Beandstandungen nicht nachvollziehen.
StateCmd schreibt brav bei jedem empfangenen Telegram den Wert in das korrespondierende Reading und ab diesem Zeitpunkt auch in die Antwort. Vorher natürlich der alte Wert, weil stateCmd ja noch nicht ausgeführt wurde.

Die Mehrfachantworten bekomme ich NIE.

Sicher, dass Du nicht irgendwelche Schweinereien / Relikte / Überbleibsel in Deinem System hast?

Sorry, aber ich kann es nicht nachvollziehen...

JoeALLb

Zitat von: Andi291 am 26 April 2018, 19:58:54
Die Mehrfachantworten bekomme ich NIE.

Sicher, dass Du nicht irgendwelche Schweinereien / Relikte / Überbleibsel in Deinem System hast?


Eigentlich schon. Werde nächste Woche nochmal genauer draufschauen, muss jetzt auf Dienstreise....

Danke, und schöne Grüße, Joe
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

JoeALLb

Dieser GAD-Name funktioniert nicht und wird durch getG18 als Reading beim eintreffen eines Telegrammes ersetzt:
6/3/201:dpt9.001:temp-desired-roomGet:nosuffix

sG
Joe
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Andi291

Poste bitte das Log5 beim Laden des Devices.
Ich nehme an, er verkraftet das "get" im Namen nicht...