V1.3.0: Geänderte Werte der 2. Kalenderzeiten werden nach kurzer Zeit wieder durch die vorigen Werte ersetzt

[hsteinme]

Im Objektbaum geänderte Werte der 2. Kalenderzeiten werden nach kurzer Zeit wieder durch die vorigen Werte ersetzt.

Worx.pdf

Dieser Fehler trat bereits anfangs bei der Einführung der 2. Mähzeiten auf. Bei Version 1.2.9 war er jedoch behoben, siehe #57 (comment)

Der Fehler tritt auch bei einem weiteren User auf, siehe https://forum.iobroker.net/post/622993

[MeisterTR]

in dem Bereich wurde seit langem nix geändert, tritt der Fehler permanent oder gelegentlich auf? hast du mal die gesendeten vom Adapter mit denen von der Desktopapp verglichen? ob die identisch sind? weil ich kann da kein Fehler erkennen, das Objekt wird richtig zusammen gesetzt und gesendet...

[hsteinme]

Die nachfolgenden Effekte treten mit Version 1.3.0 bei mir permanent auf:

• Bei Änderung einer 1. Zeit:

  • Zeit 1 wird korrekt übernommen
  • Zeit 2 wird vollständig ausgenullt
  • DeskApp erhält einen Update der Daten und zeigt die gleichen Werte wie der Adapter an

• Bei Änderung einer 2. Zeit:

  • Zeit 1 bleibt korrekt erhalten
  • Geänderte Zeit 2 wird kurz angezeigt und sogleich wieder durch den vorherigen Wert ersetzt.
  • DeskApp erhält einen Update der Daten und zeigt die gleichen Werte wie der Adapter an

Wenn ich das Debug-Log des Adapters korrekt interpretiere, so schickt er bei einer Änderung der 1. oder 2. Zeit nur einen Teil der Struktur von sc, und zwar entweder nur sc.d oder nur sc.dd.

Wenn ich die Bestätigungsbox der DeskApp nach Änderung einer 1. oder 2. Zeit korrekt interpretiere, so schickt die DeskApp zwar auch nur einen Teil der Struktur von sc, jedoch einen weitaus größeren Teil als der Adapter, nämlich sc.d, sc.dd, sc.m und sc.p.

Vielleicht liegt in diesem unterschiedlichen Sendeverhalten ein Erklärungsansatz für die beiden oben beschriebenen Fehlerfälle.

Wenn Du mir eine Version aufbereiten würdest, die probeweise das oben beschriebene Sendeverhalten der Desktop App verwendet, kann ich damit gerne meine Tests wiederholen.

[MeisterTR]

gesagt getan, 1.3.2 ist raus

[hsteinme]

Probleme sind mit 1.3.2 gelöst. Danke schön!

[hsteinme]

DRINGEND ::: DRINGEND ::: DRINGEND ::: DRINGEND ::: DRINGEND

Gestern Abend habe ich im Dunklen meinen Mäher auf dem Rasen einfangen müssen, da er ohne meinen Auftrag losgefahren ist. Die Ursache seines Verhaltens war ein Kalender-Auftrag des worx-Adapters der auch einen nicht gewollten One Time Scheduler Auftrag an den Mäher schickte. Zu den Details:

Am späten Nachmittag hatte ich den Mäher per One Time Scheduler (= OTS) über eine App für 75 Minuten zum Mähen geschickt.

#02297 - 15/05/2021 17:47:05 - Mower start sequence
#02298 - 15/05/2021 17:47:05 - [One Time Scheduler] - work start 1h15min, 19.53Volt
#02299 - 15/05/2021 17:47:05 - [One Time Scheduler] - App start Request

Die daraufhin vom Adapter erhaltene MQTT Message enthält auch die OTS Auftragsdaten:

2021-05-15 17:47:08.855 - debug: worx.0 (28310) GET MQTT DATA from API: {"cfg":{"id":1,"lg":"it","tm":"17:47:05","dt":"15/05/2021","sc":{"m":1,"distm":0,"ots":{"bc":0,"wtm":75},"p":0,"d":[...],"dd":[...]}, ...},...}

Die Werte der OTS_Struktur "ots":{"bc":0,"wtm":75} schlummern danach unverändert in den MQTT Strukturen des Mähers und des MQTT Servers sowie in den Datenpunkten des Adapters.

Spätabends hat dann eines meiner Java-Skripte beim Adapter die Änderung einer Mähzeit im Kalender beauftragt, worauf dieser folgendes Richtung Mäher schickte:

2021-05-15 22:43:10.015 - debug: worx.0 (28310) Worxcloud MQTT sendMessage to 201999999 Message: {"sc":{"m":1,"distm":0,"ots":{"bc":0,"wtm":75},"p":0"d":[...],"dd":[...]}, ...},...}

Dieses neuerliche Senden der OTS-Daten versteht der Mäher als einen neuen OTS-Auftrag und führt diesen dann auch aus:

#00386 - 15/05/2021 22:42:59 - Mower start sequence
#00387 - 15/05/2021 22:42:59 - [One Time Scheduler] - work start 1h15min, 19.82Volt
#00388 - 15/05/2021 22:42:59 - [One Time Scheduler] - App start Request

Dieses unerwünschte Senden der OTS-Struktur ist seit der Änderung zu Version 1.3.2 im Adapter eingebaut. Ein Blick in die Logdatei und in den Code von main.js zeigt, dass neben den angefragten MQTT Elementen zusätzlich alle restlichen Elemente der sc Struktur im Falle einer Mähzeitenänderung Richtung Mäher geschickt werden, insbesondere also auch die Strukturelemente ots und distm.

Bei der letztjährigen Beschäftigung mit Issue #53 hatte uns Positec bereits darauf hingewiesen, dass das zusätzliche Senden der beiden letztgenannten Elemente bei einem Mähzeiten-Auftrag unerwünschte Seiteneffekte haben kann: Bei ots kann es zum Starten des Mähers führen (wie bei mir gestern Abend) und bei distm kann es zum Sperren des Mähers führen (Partymodus).

Zu Details siehe hier: #53 (comment)

Bitte die Änderung zu 1.3.2 so korrigieren, dass wirklich nur die Elemente sc.d, sc.dd, sc.m und sc.p bei Mähzeitenänderungen losgeschickt werden.

(Ich möchte mir nicht ausmalen, was passiert, wenn bei einer ungewollten Ausfahrt des Mähers tagsüber Hundeschwänze oder Kinderhände auf dem Rasen liegen oder in der Nacht eine Igelfamilie über den Rasen spaziert. Daher bitte dieses Issue als eine dringende Angelegenheit behandeln.)

[MeisterTR]

Fix es gleich..

[MeisterTR]

so in der 1.3.3 geändert, bitte nochmal testen

[hsteinme]

Danke für die schnelle Lieferung. Der Nachtest war insofern erfolgreich, als die ots-Struktur bei Mähzeiten-Änderungen nicht mehr mit geschickt wird. Der Nachtest war aber insofern nicht erfolgreich, als das Element sc.distm weiterhin bei Mähzeiten-Änderungen mit geschickt wird.

Darf ich Dir bitte in diesem Zusammenhang ein Statement von Dir aus dem letzten Jahr (#53 (comment)) in Erinnerung rufen:

ich sachätze ich muss wie positec schrib distm auch noch aus dem setup entfernen, dann sollte es glaub ich gehen, mach ich die Tage.

[MeisterTR]

auch erledigt in der 1.3.5

[hsteinme]

sc.distm wird auch in 1.3.5 weiterhin bei einer Änderung einer Mähzeit geschickt. Beispiel: Dauer der 1. Mähzeit sonntags wurde geändert.

2021-05-21 18:21:23.443  - �[32minfo�[39m: worx.0 (22509) starting. Version 1.3.5 in /opt/iobroker/node_modules/iobroker.worx, node: v12.18.4, js-controller: 3.2.16
...
2021-05-21 18:21:38.336  - �[34mdebug�[39m: worx.0 (22509) Mowing time change at d to: {"m":1,"distm":0,"p":0,"d":[["00:00",99,0],["00:00",0,0],["00:00",0,0],["00:00",0,0],["00:00",0,0],["09:40",180,0],["00:00",0,0]],"dd":[["00:00",0,0],["00:00",0,0],["00:00",0,0],["00:00",0,0],["00:00",0,0],["00:00",0,0],["00:00",0,0]]}
2021-05-21 18:21:38.337  - �[34mdebug�[39m: worx.0 (22509) Worxcloud MQTT sendMessage to 999999 Message: {"sc":{"m":1,"distm":0,"p":0,"d":[["00:00",99,0],["00:00",0,0],["00:00",0,0],["00:00",0,0],["00:00",0,0],["09:40",180,0],["00:00",0,0]],"dd":[["00:00",0,0],["00:00",0,0],["00:00",0,0],["00:00",0,0],["00:00",0,0],["00:00",0,0],["00:00",0,0]]}}
2021-05-21 18:21:38.338  - �[34mdebug�[39m: worx.0 (22509) test cfg: 0 valID: 1 val: 99 sval: 99