UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[hsteinme]

@cosmicbase Der Ansatz, die Zeitumrechnung gleich im ersten on-Statement durchzuführen, ist ein guter Ansatz. Mit Deinem zweiten on-Statement läufst Du nämlich in eine Endlosschleife hinein: Wenn sich idBladeWorkTimeCurrent ändert, berechnest Du den Wert neu und änderst ihn damit erneut. Also schlägt wieder die zweite on-Angabe zu usw. usf.

'use strict';

const idBladeWorkTime = 'worx.0.99999999999999999999.rawMqtt.raw.blade_work_time';
const idBladeWorkTimeReset = 'worx.0.99999999999999999999.rawMqtt.raw.blade_work_time_reset';
const idBladeWorkTimeCurrent = '0_userdata.0.MyWorx.99999999999999999999.blade_work_time_current';

function zweiStellig(zahl) {
    return zahl < 10 ? '0' + zahl : zahl
}

function stundenMinuten(minuten) {
    return parseInt(minuten / 60) + ':' + zweiStellig(minuten % 60);
}

on ({id: [idBladeWorkTime, idBladeWorkTimeReset], change: 'ne'}, function() {
    setState(idBladeWorkTimeCurrent, stundenMinuten(getState('idBladeWorkTime').val - getState('idBladeWorkTimeReset').val));
})

Wegen einer besseren Übersichtlichkeit ist es sinnvoll, die Zeitumrechnung in eine eigene Funktion auszulagern.

Wichtig: blade_work_time_current enthält jetzt keine Zahl mehr, sondern einen String. Also diesen bestehenden Datenpunkt zunächst löschen und als Typ String neu anlegen.

[Cosmicbase]

@hsteinme vielen Dank für deine Hilfe.
Die Idee die Zeit in h/min umzurechnen war nur so ein Gedanke der sicherlich Sinn macht.
Den DP zu löschen und Zahl in String anzulegen habe ich verstanden.
Leider kenn ich mich mit JS so gut wie gar nicht aus, deswegen meine Fragen.
Kann ich dein Skript jetzt so anlegen oder sollten meine Funktionen aus 2 JS bestehen?
Eins für Bladetime und 1 für Zeitumwandlung.

[hsteinme]

@cosmicbase Nimm das Skript, das ich Dir heute Morgen aufgeschrieben habe.

[Cosmicbase]

@hsteinme Wird gemacht.

Vielen herzlichen Dank

[Cosmicbase]

@hsteinme
Wird der 0_userdata.0.worx.blade_work_time_current erst befüllt wenn sich eine Differenz ergibt?
Im Moment steht weder false noch 0 drin.
Muss aber mit mähen auch noch warten weil ich frisch angesäht habe.
Lediglich einen Kantenschnitt habe ich durchgeführt.

Aber da hat sich auch nix an den Werten von

worx.0.999999999999999999.rawMqtt.raw.blade_work_time
und
worx.0.999999999999999999.rawMqtt.raw.blade_work_time_reset

geändert.:confused:

Der Datenpunkt ist jetzt string statt number.
JS wird unter Skripte/Common ausgeführt. Sollte doch richtig sein.
Die Rechte 664 habe ich unberührt lassen.

Kuck dir mal den Screenshot an.

[hsteinme]

@cosmicbase sagte in Adapter: Worx Landroid:

Wird der 0_userdata.0.worx.blade_work_time_current erst befüllt wenn sich eine Differenz ergibt?

Hier steht die Antwort, wann der private Datenpunkt gefüllt wird: https://forum.iobroker.net/post/639077

@cosmicbase sagte in Adapter: Worx Landroid:

Im Moment steht weder false noch 0 drin.

String-Datenpunkte sind anfänglich immer leer.

[Cosmicbase]

@hsteinme
Habe dein Skript ausgiebig getestet. Im Adapter ist eine Differenz vorhanden, jedoch das JS Skript spuckt immer noch 0,00h/min aus.
Datenpunkt ist auch noch bei 0.
Irgendwas muss im Skript noch nicht stimmen.
Auch in der App wird unter Klingenlaufzeit 2h angezeigt, was ohne Umwandlung immerhin 120min wären.

Hier sieht man das eine Differenz zwischen blade_work_time und blade_work_time_reset gebildet wurde.
Daraus sollte das js Skript doch die Zeit in Minuten oder mit Umwandlung in h/min ausgeben.

Ich werde heute noch das eingangs erwähnte Skript ohne Umwandlung probieren. Also nur die Ausgabe in Minuten.

[Cosmicbase]

@hsteinme said in Adapter: Worx Landroid:

Für diesen Datenpunkt vergibst Du den Typ Zahl, keinen Maximalwert, keine Maßeinheit sowie Lese- und Schreibberechtigungen.

Bedeutet keine Lese und Schreibberechtigung = 0 oder die typische Lese-Schreibberechtigung = 664 ?

Kannst du nochmal einen Blich auf das oder die Skripte werfen?

Der 0.Userdata DP bleibt auf Wert 0 bzw. 0:00 obwohl scheinbar die blade_time_current mit Daten befüllt wird.

[Cosmicbase]

Jetzt hab ich mal die 2 Datenpunkte nen Screenshoot gemacht.

Einmal läuft ein JS mit der Umrechnung in h/min und einmal ganz normal in Minuten.
Leider haben die Skripte zu keinem Zeitpunkt eine klare Differenz errechnet.

[hsteinme]

@cosmicbase Sorry, in meinem Skript hatte das Fehlerteufelchen zugeschlagen. Bitte tausche die nachfolgend zitierte Zeile in dem Skript aus:

alt:

    setState(idBladeWorkTimeCurrent, stundenMinuten(getState('idBladeWorkTime').val - getState('idBladeWorkTimeReset').val));

neu:

    setState(idBladeWorkTimeCurrent, stundenMinuten(getState(idBladeWorkTime).val - getState(idBladeWorkTimeReset).val));

Starte das geänderte Skript. lass Deinem Mäher eine halbe Stunde lang mähen und beobachte dabei den privaten Datenpunkt nach frühestens 10 Minuten.

[Cosmicbase]

@hsteinme said in Adapter: Worx Landroid:

setState(idBladeWorkTimeCurrent, stundenMinuten(getState(idBladeWorkTime).val - getState(idBladeWorkTimeReset).val));

Super das es jetzt klappt. Zumindest nach dem ich das JS und den Adapter neu gestartet habe war es vollendet (siehe Bild).
Läuft der manuelle Kantenschnitt auch die Klingenzeit mit ein?

Das ganze könnte man auch mit dem Batterie cycle machen!

Kannst du mir das im Skript anpassen mit den stundenMinuten? Sollten ja Ladezyklen sein und keine Zeit.

'use strict';

const idBatterieCycleTime = 'worx.0.99999999999999999.rawMqtt.raw.battery_charge_cycles';
const idBatterieCycleTimeReset = 'worx.0.99999999999999999.rawMqtt.raw.battery_charge_cycles_reset';
const idBatterieCycleTimeCurrent = '0_userdata.0.worx.batterie_cycle_time_current';

on ({id: [idBatterieCycleTime, idBatterieCycleTimeReset], change: 'ne'}, function() {
setState(idBatterieCycleTimeCurrent, stundenMinuten(getState(idBatterieCycleTime).val - getState(idBatterieCycleTimeReset).val));
})

Danke für deine Arbeit.

PS:

Was ich bemerkt habe das auch nach 30 Minuten mähen sich nichts an den Raw Werten geändert hat. Scheinbar werden die Daten von der Cloud nur unregelmäßig zur Verfügung gestellt. Könnte natürlich auch sein das die Klingenzeit immer erst beim erreichen der vollen Stundnzahl aktualisiert wird. Schließlich wird sie in der App auch nur mit Stunden angezeigt.

Neues Update:

Wie du schon im GitHub geschrieben hast hat sich irgendwo bei der Bereitstellung der Daten aus der Cloud ein Fehler eingeschlichen.
Habe einen Klingenreset gemacht und dann ist die Klingenzeit ins Minus gegangen weil der Reset Wert höher ist als die tatsächliche Klingenzeit. Ich weiß das dies zwar wieder überschrieben wird, aber irgendwie komisch.
Hoffe das hier irgendwas verbessert wird.

[hsteinme]

@cosmicbase sagte in Adapter: Worx Landroid:

Das ganze könnte man auch mit dem Batterie cycle machen!
Kannst du mir das im Skript anpassen mit den stundenMinuten? Sollten ja Ladezyklen sein und keine Zeit.

Dann schmeiß halt stundenMinuten mit dem zugehörigen Klammernpaar aus dem Skript raus.

Nebenbei; Die Verwendung von "time" in der Benamsung des privaten Datenpunktes und der Variablen ist extrem unglücklich, denn "Sollten ja Ladezyklen sein und keine Zeit."

[Cosmicbase]

@hsteinme

'use strict';
 
const idBatterieCycleTime = 'worx.0.9999999999999999.rawMqtt.raw.battery_charge_cycles';
const idBatterieCycleTimeReset = 'worx.0.9999999999999999.rawMqtt.raw.battery_charge_cycles_reset';
const idBatterieCycleTimeCurrent = '0_userdata.0.worx.batterie_cycle_time_current';

on ({id: [idBatterieCycleTime, idBatterieCycleTimeReset], change: 'ne'}, function() {
    setState(idBatterieCycleTimeCurrent, getState(idBatterieCycleTime).val - getState(idBatterieCycleTimeReset).val);
})

So funktioniert auch die Batterie Cycle.

Aber was mich ein wenig anwiedert ist die Tatsache das mal die Reset Werte unter RAW größer mal kleiner sind.
So kommt es im privaten DP zu einem Minus Wert.

FINDE DEN FEHLER, bzw. DIE FEHLER!!!

Wie kann man dem Problem entgegen wirken das die Werte sich nicht immer drehen?
Und warum werden die RAW Werte so zögerlich aktualisiert?

Eventuell im JS ne Funktion das immer automatisch der größte Wert subtrahiert wird?

Interessanterweise ist in der App immer alles richtig dargestellt...

[hsteinme]

@cosmicbase sagte in Adapter: Worx Landroid:

Aber was mich ein wenig anwiedert

Geht's nicht auch 'ne Nummer kleiner?

[RalfEngelberth]

Hallo, ich habe folgendes Problem.
Bis lang hat der Worksadapter bei mir prima funktionier.
Seit dem letzten Gesamtupdate von IoBroker sowie auch JS Contoler funktioniert meine Ansteuerung über VIS an den Mäher nicht mehr.
Ich habe mich über den Worksadapter bei Works angemeldet.

Die Datenpunkte (welche ich auch schon mal komplett gelöscht habe) wurden auch angelegt.

Hier erfolgt aber keine Aktualisierung.

Im Protokoll habe ich mehrere Fehlermeldungen

Was mich wundert, die Seriennummer in den Objekten endet mit der *****1286
Im Fehlerprotokoll endet aber die Seriennummer mit ****3000

Hat jemand eine Lösung?

[RalfEngelberth]

Hat keiner eine Lösung?

[arteck]

@ralfengelberth welcheist den jetzt dir richtige ?

ausserdem ist es schnuppe ob du die nummer maskeirst oder nicht.. kann ehh keiner was mit angangen

[RalfEngelberth]

@arteck Das in den Objekten
Die 3000 in der Log gibt es nicht

[arteck]

@ralfengelberth nein welche ist denn jetzt die die zu DEINEM Worx gehört.. ich meine ist die sereinnummer

[RalfEngelberth]

@arteck 20193019840102591286