Qubino ZMNHSD1: Ausschalttimer läßt sich nicht ändern

Begonnen von mahowi, 21 Februar 2017, 20:11:27

Vorheriges Thema - Nächstes Thema

mahowi

Nachdem gerade noch geschrieben habe, daß der DIN Dimmer von Qubino einwandfrei funktioniert, habe ich festgestellt, daß doch nicht alles geht wie gedacht.

Über den Parameter 11 läßt sich ein Timer zum automatischen Ausschalten setzen (1-32536 Sekunden). Standard ist 0, die Funktion ist also abgeschaltet. Gerade habe ich versucht, den Wert auf 300 zu ändern mit:
set ZWave_SWITCH_BINARY_6 configAutomaticTurningOffOutputAfter11 300

Danach wird die Geräteseite in FHEM neu geladen, der Wert ändert sich aber nicht. Im Log erscheint:
2017.02.21 19:59:44.638 3 : ZWave set ZWave_SWITCH_BINARY_6 configAutomaticTurningOffOutputAfter11 300
2017.02.21 19:59:44.778 1 : ERROR: max send retries reached, removing 010c0013060570040b0112c25f762 from dongle sendstack
2017.02.21 19:59:49.643 2 : ZWave: No ACK from ZWave_SWITCH_BINARY_6 after 5s for sentset:13060570040b0112c25f7


Schalten funktioniert, auch das Setzen anderer Parameter wie z.B. configPowerReportingInWattsByTime42.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

krikan

Zitat010c0013060570040b0112c25f762
Das Funktelegramm ist mMn "kaputt" und darum kann das nicht funktionieren. Das ist eine ungerade Anzahl von Zeichen und eigentlich müsste das eine gerade Anzahl sein.
Ob das an der XML-Config liegt oder an einem anderen Problem, kann ich mir -mangels FHEM-Zugriffs- momentan nicht erklaeren.

Du kannst den Konfigurationsparameter aber auch mit configWord bzw. configLong setzen; das sollte (immer) funktionieren.

mahowi

Da scheint wohl irgendwas an der XML-Config nicht zu passen.

set ZWave_SWITCH_BINARY_6 configWord 11 300 funktioniert.

get ZWave_SWITCH_BINARY_6 configAutomaticTurningOffOutputAfter11 zeigt danach den eingestellten Wert an.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

krikan

Zitat von: mahowi am 21 Februar 2017, 21:19:44
Da scheint wohl irgendwas an der XML-Config nicht zu passen.
Bestreite ich erst mal frech.  ;) Kann naemlich keinen Fehler in Trockenübung erkennen. Schaue ich mir an, sobald ich in einigen Tagen wieder FHEM-Zugriff habe.

mahowi

Ich geb ja zu, ich habe keine Ahnung, woran es liegen könnte.  8)

Ich kann nur sehen, das bei jedem Versuch ein anderer Wert, der sich in den letzten 4 Stellen unterscheidet, gesendet wurde, z.B. 010c0013060570040b0112c25c541, 010c0013060570040b0112c25e323 oder 010c0013060570040b0112c250bad. Und dabei blieb der Wert immer auf 0.
Mit configWord wurde der Wert sofort geändert. Und die Lampe schaltet sich auch brav nach 5 Minuten aus.

Wenn Du wieder an Dein FHEM dran kommst, kannst Du Dich ja nochmal melden. Ich hoffe, ich kann dann bei der Fehlersuche helfen.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

krikan

Zitat von: mahowi am 21 Februar 2017, 21:56:20
Ich geb ja zu, ich habe keine Ahnung, woran es liegen könnte.  8)
Ich auch noch nicht.  :)

Zitat
Ich kann nur sehen, das bei jedem Versuch ein anderer Wert, der sich in den letzten 4 Stellen unterscheidet, gesendet wurde, z.B. 010c0013060570040b0112c25c541, 010c0013060570040b0112c25e323 oder 010c0013060570040b0112c250bad. Und dabei blieb der Wert immer auf 0.
Letzten 4 Stellen sind CallbackId und Checksum. Wichtig ist der vordere Teil. Den müsstest Du mit dem raw-Wert vom configWord-Befehl vergleichen. Da ist mMn eine 1 zu viel. Keine Ahnung, wie das kommt.

Zitat, kannst Du Dich ja nochmal melden.
Sowieso; XMLs brauchen auch ein Update.

mahowi

#6
Mit "verbose 5" auf dem Stick bekomme ich für "configWord 11 300" im Log:
2017-02-21 22:11:52.700 ZWave ZWave_SWITCH_BINARY_6 configWord 11 300
2017.02.21 22:11:52.702 5 : ACK received, WaitForAck=>2 for 010d0013060670040b02012c254ade
2017.02.21 22:11:52.703 4 : ZWDongle_Read ZME_UZB1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2017.02.21 22:11:52.704 5 : SW: 06
2017.02.21 22:11:52.706 5 : ZME_UZB1: dispatch 011301
2017.02.21 22:11:52.711 4 : ZWDongle_Read ZME_UZB1: rcvd 00134a000002 (request ZW_SEND_DATA), sending ACK
2017.02.21 22:11:52.712 5 : SW: 06
2017.02.21 22:11:52.713 5 : device ack reveived, removing 010d0013060670040b02012c254ade from dongle sendstack
2017.02.21 22:11:52.714 5 : ZME_UZB1: dispatch 00134a000002
2017.02.21 22:11:52.715 4 : CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:4a
2017.02.21 22:11:52.715 4 : ZME_UZB1 transmit OK for CB 4a, target ZWave_SWITCH_BINARY_6


Mit "configAutomaticTurningOffOutputAfter11 300":
2017-02-21 22:14:07.434 ZWave ZWave_SWITCH_BINARY_6 configAutomaticTurningOffOutputAfter11 300
2017.02.21 22:14:07.446 4 : ZWDongle_Read ZME_UZB1: NACK received
2017.02.21 22:14:07.447 5 : SW: 010c0013060570040b0112c254ef9
2017.02.21 22:14:07.453 4 : ZWDongle_Read ZME_UZB1: NACK received
2017.02.21 22:14:07.455 5 : SW: 010c0013060570040b0112c254ef9
2017.02.21 22:14:07.459 4 : ZWDongle_Read ZME_UZB1: NACK received
2017.02.21 22:14:07.461 5 : SW: 010c0013060570040b0112c254ef9
2017.02.21 22:14:07.466 4 : ZWDongle_Read ZME_UZB1: NACK received
2017.02.21 22:14:07.467 1 : ERROR: max send retries reached, removing 010c0013060570040b0112c254ef9 from dongle sendstack


010d0013060670040b02012c25 ist der Wert ohne CallbackID und Checksum, der funktioniert.

010c0013060570040b0112c25 ist der "falsche" Wert. Die Unterschiede habe ich mal hervorgehoben.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

krikan

Danke  :)

010d0013060670040b02012c25 ist der Wert ohne CallbackID und Checksum, der funktioniert.

010c0013060570040b0112c25 ist der "falsche" Wert. Die Unterschiede habe ich mal hervorgehoben.

"Gefaehrliche" Analyse aus dem Kopf:
0d/0c und 06/05 sind Laengenangaben.
02/01 sind Größenangaben zum Parameter.

Also iW falsch bei FHEM (Rest korrigiert sich quasi automatisch)
Größenangabe müsste 02 sein statt 01 und bei Parameterwert fehlt die Auffüllung mit 0 auf 01.

Aufbaufehler im XML finde ich immer noch nicht und der Befehl "configAutomaticTurningOn.*" hat den gleichen Aufbau. Funktioniert der?




mahowi

Nein, der geht auch nicht:

2017.02.21 23:03:33.867 3 : ZWave set ZWave_SWITCH_BINARY_6 configAutomaticTurningOnOutputAfterSet12 300
2017.02.21 23:03:33.953 1 : ERROR: max send retries reached, removing 010c0013060570040c0112c25110b from dongle sendstack
2017.02.21 23:03:38.870 2 : ZWave: No ACK from ZWave_SWITCH_BINARY_6 after 5s for sentset:13060570040c0112c2511


"configWord 12 300" geht hingegen wieder.
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

krikan

Passt und da ich mich Config-XML-maeßig immer noch unschuldig fühle, brauchen wir wohl einen richtigen Entwickler  :) .

@Rudi: Könntest Du Dir das bei Gelegenheit bitte einmal anschauen?

mahowi

Dann geh ich mal so langsam ins Bett.  ;)
Gute Nacht!
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

krikan


   <Value type="short" genre="config" instance="1" index="11" label="Automatic turning off output after set time" size="1" min="0" max="32536" value="0">

Die XML-Configs widersprechen sich und ich bin wohl schuldig:
type="short" -> A Short can represent a number from 0 to 65535
size="1" -> Specify the size of the value in bytes. (In 1 Byte 0 to 65535 zu bekommen ist schwierig.)

Ich kann also die size auf 2 setzen und alles ist eventuell gut (ungetestet).
Dennoch habe ich ein Störgefühl beim derzeitigen Erzeugen der Nachrichten, bin aber unsicher, ob sich solche Widersprüche sinnvoll abfangen lassen.