Wozu ist der ack-Flag da?
-
@cash sagte in js-controller 3.3 jetzt im STABLE!:
Wenn ich den nun per vis setze wird er mit ack false gesetzt oder?
oder?
keine Ahnung wie vis den setzt.
möglicherweise kommt das auch auf das Widget an.@cash sagte in js-controller 3.3 jetzt im STABLE!:
Muss Yahka den Wert mit ack=true setzen?
Von dem Zeug habe ich gar keine Ahnung.
Ist Homekit ein Adapter?
Welche Datenpunkte setzt er? -
@cash Wenn der Script den Datenpunkt erfolgreich verarbeitet hat, bestätigt er diesen mit den selben Wert und ack=true
-
@idlebit sagte in js-controller 3.3 jetzt im STABLE!:
@cash Wenn der Script den Datenpunkt erfolgreich verarbeitet hat bestätigt er diesen mit den selben Wert und ack=true
Nein!
Das ist zwar genau das Prinzip.
Datenpunkt X wird geändert.
Ack=true bedeutet da ist alles fertig
Ack=false bedeuitet: da muss jetzt einer aktiv werden.
Dieser fürht dann mit dem Wert seine Aktion aus und setzt anschließend den Ack auf true um zu zeigen, dass die "Aufgabe erfüllt" wurde.Bei Skripten müsste der Ersteller das dann entsprechend umsetzen. Und zwar vom triggern auf den geänderten state nur wenn ack=false und anschließendes setzen des ack-flags auf true
Wie gesagt ist das alles die Theorie, was noch angepasst werden muss muss jetzt gesehen werden
-
@cash Grundsätzlich sollen die Adapter ein ACK=True setzen, als Bestätigung, dass die Änderung auch durchgeführt wurden.
VIS wird immer ACK=False setzen, da es nur eine Änderung anstößt, aber nicht durchführt. Der Adapter setzt dann nach Durchführung auf True.Bei Datenpunkten hinter den kein Adapter steht (also in der Regel 0_userdata.0) musst Du, wenn gewünscht nun das ACK=True setzen.
Solange Du den Datenpunkt selbst erstellt hat, wird VIS wie Du richtig sagst, den Datenpunkt mit ACK=false setzten. Dein Skript kann das nun bestätigen (z.Bsp Blockly = aktualisiere) oder nicht (z. Bsp Blockly = steuere).
Und richtig, YAHKA wird nach Umsetzung das ACK-Flag setzen.Im Prinzip ist doch die Frage, ob ein ACK-Flag gesetzt werden muss folgende:
- Bist Du ein Adapterentwickler, musst Du wenn Du einen Wert setzt auch ACK=true setzen - und deshalb macht die Warnung Sinn.
- Bist Du kein Adapterentwickler dann brauchst Du das im Prinzip nicht. Ich gehe mal davon aus, ohne die Internas zu kennen, dass die Warnung nur bei Adaptern auftaucht, aber nicht wenn DU mit VIS oder Deine Logikmaschine einen Wert ohne ACK setzt.
Im Gegenteil Du "steuerst" ja gerade mit dem NICHT-ACK Flag setzten in einem Skript, dass der Adapter erkennt - ah eine Änderung - muss was tun - und bestätigen, dass das Gemachte erfolgreich war. Meines Erachtens ist für den Adapter ein ACK=false ein Filtermechanismus um noch nicht gemachte Änderungen schnell ausfiltern zu können.
Im Prinzip ist für Dich in einem Skript die Meldung in meinen Augen als Anwender irrelevant. Die Meldung ist mE nur für Adapterentwickler interessant, falls die vergessen haben - Werte mit ACK zu schreiben und kommt mE auch nicht, wenn Du selbst was unter 0_userdata.0 unbestätigt schreibst.
-
@homoran Wie Nein!
Genau das sagte ich doch?!
Wenn nicht verarbeitet ack = false, wenn verarbeitet ack = true. -
@mickym sagte in js-controller 3.3 jetzt im STABLE!:
Ich gehe mal davon aus, ohne die Internas zu kennen, dass die Warnung nur bei Adaptern auftaucht, aber nicht wenn DU mit VIS oder Deine Logikmaschine einen Wert ohne ACK setzt.
da sind wir schon zwei!
Ich fabuliere mal weiter: Vielleicht ist auch der Namespace 0_userdata.0 (und javascript.0) von der Kontrolle ausgenommen.
Ich habe diese Meldungen (noch) nicht.@mickym sagte in js-controller 3.3 jetzt im STABLE!:
Im Gegenteil Du "steuerst" ja gerade mit dem NICHT-ACK Flag setzten in einem Skript, dass der Adapter erkennt - ah eine Änderung - muss was tun - und bestätigen, dass das Gemachte erfolgreich war.
Das war das was ich eben meinte:
Wenn man das Ganze auch für eigene Scripte zu Ende denkt, müsste/könnte man auch dort mit den Flags arbeiten um z.B. bei einem Datenpunkt zu erkennen, ob eine Bedienung über die vis stattgefunden hatte und nur dann mit dem eigenen Skript zu reagieren und anschließend (wie ein Adapter) ack=true zu setzen -
@idlebit sagte in js-controller 3.3 jetzt im STABLE!:
Genau das sagte ich doch?!
dann war das unglücklich formuliert:
@idlebit sagte in js-controller 3.3 jetzt im STABLE!:
Wenn der Script den Datenpunkt erfolgreich verarbeitet hat, bestätigt er diesen mit den selben Wert und ack=true
Das bedeutete für mich, dass jedes Skript das von sich aus macht
-
@homoran Ok, ich meinte eher das es so sein sollte wenn man einen Script schreibt
Hier noch ein Snipped:
on({id: dp_present, change: 'ne'}, (obj)=>{ ultraCooleLogic(obj.state.val); setState(obj.id, obj.state.val, true); }); -
@idlebit NNaaajjjaaaaaaa ... wenn die Meldung kommt dann wird ein Read-Only State geschrieben ... die Hauptfrage für mich ist : Warum denn überhaupt? Aber ja eine Lösung (die pragmatischste aber nicht die beste) ist das von Dir vorgeschlagene. Die richtige Lösung ist zu schauen warum man überhaupt auf ein Read-Only-State schreibt und warum
-
@homoran sagte: Das bedeutete für mich, dass jedes Skript das von sich aus macht
Nur dann, wenn das Skript in den (virtuellen) Datenpunkt schreibt. Wird der Datenpunkt im Skript nur gelesen, kann/sollte ack auf false bleiben.
-
@apollon77 sagte in js-controller 3.3 jetzt im STABLE!:
wenn die Meldung kommt dann wird ein Read-Only State geschrieben
cool, es geht also gar nicht um ack
Danke für die Info
-
@homoran sagte in js-controller 3.3 jetzt im STABLE!:
@mickym sagte in js-controller 3.3 jetzt im STABLE!:
Im Gegenteil Du "steuerst" ja gerade mit dem NICHT-ACK Flag setzten in einem Skript, dass der Adapter erkennt - ah eine Änderung - muss was tun - und bestätigen, dass das Gemachte erfolgreich war.
Das war das was ich eben meinte:
Wenn man das Ganze auch für eigene Scripte zu Ende denkt, müsste/könnte man auch dort mit den Flags arbeiten um z.B. bei einem Datenpunkt zu erkennen, ob eine Bedienung über die vis stattgefunden hatte und nur dann mit dem eigenen Skript zu reagieren und anschließend (wie ein Adapter) ack=true zu setzenIn meinen Skripts (auch mit NodeRed
) - mache ich das auch so. Sprich ändere ich ein Objekt in einem Adapter - dann wird ACK=false (also nicht gesetzt).
Schreibe ich hingegen selbst einen Wert unter 0_userdata.0 - setze ich immer das ACK=true Flag, da es ja sonst niemand macht.Im Prinzip muss ich als Skript-Schreiber mir nur überlegen, welchen Wert ich aktualisiere und mir überlegen - gibts da jemand oder was, der meinen Wert bestätigen kann.
-
Auch wenn es schon diskutiert wurde noch mein "senf dazu"
Kurz ist es:
- ack=false bedeutet "Der gesetzte Wert ist ein Steuerkommando was besagt das der State eine Aktion ausführt mit diesem Wert. Erstmal egal was dahinter passiert. Auch egal ob die Logik wird den Wert so weitersendet oder was anderes damit tut. Mit ack=false hat der Wert faktisch "keine klare Bedeutung" weil unklar ist was der echte Gerätszustand ist.
- ack=true bedeutet "Das ist der aktuelle Wert der so vom "gerät" bzw von der "Logik die hinter diesem State liegt" bestätigt wurde (daher auch der name ack=="acknowledged"). Das ist damit kein Kommando sondern ein" Fakt"
@cash sagte in js-controller 3.3 jetzt im STABLE!:
Angenommen ich habe einen Datenpunkt erstellt z. B. automatisch saugen als boolean. Einmal täglich läuft ein Script welches den Sauger startet aber nur wenn der Datenpunkt auf true steht.
Wenn ich den nun per vis setze wird er mit ack false gesetzt oder? Muss das nun per ack = true erfolgen?Interessanter Fall. Formal korrekt wäre das das true mit ack=false geschrieben wurd und dein Skript wenn es den Sauger dann "einmalig" gestartet hat das state mit "value=false, ack=true" quasi zurücksetzt.
Und korrekt vis setzt immer ack=false weil Vis im Normalfall immer etweas steuern will!@cash sagte in js-controller 3.3 jetzt im STABLE!:
Angenommen ich habe einen eigenen Datenpunkt erstellt "Licht" diesen habe ich in Yahka Adapter eingebunden. Wenn ich per Homekit das Licht auf true setzte reagiert mein Script und schaltet das Licht ein.
Muss Yahka den Wert mit ack=true setzen? Oder muss ich per Script die Änderung mit true bestätigen?Yahka MUSS (wenn es ein Steuerkommando ist!) mit ack=false setzen weil sonst keine Steueraktion erfolgen sollte. Und dein Skript sollte auf "ack=true" nicht reagieren.
Ob Du die Aktion mit "true" bestätigst oder nicht bleibt Dir überlassen (in dem Fall gehen ja andere States - nämlich die der Lichter - auf true. Wenn dein State also ein "Button" ist dann weiss der ja eh nicht was der echte Status ist (kannst du deinem Wand-taster ja auch nicht ansehen). Also einen Button zu bestätigen ist faktisch falsch. Wenn es ein Schalter wäre dann macht es sinn zu bestätigen weil der einen klaren Zustand hat.
-
Hab noch eine Detailfrage in Verbindung mit dem ack-Flag
folgende Situation:
Im tvprogram-vis widget schreibe ich diverse Daten direkt in Datenpunkte.
Darunter sind auch Datenpunkte, die auf readonly stehen, da der Nutzer diese nicht beschreiben sollte.
Leider bietet die vis-Funktion setValue nicht die Möglichkeit optional das ack-Flag mit anzugeben.Es gibt jetzt 2 Möglichkeiten wie man das beheben könnte:
- in vis wird die Funktion setValue erweitert, so das man das ackFlag=true setzen kann
- ich sende die Informationen erst per sendTo an den Adapter, so das der Adapter die Daten dann in den Datenpunkt schreibt.
Wie sollen wir damit umgtehen?
-
@oliverio sagte: Darunter sind auch Datenpunkte, die auf readonly stehen, da der Nutzer diese nicht beschreiben sollte.
Du willst sie trotzdem per Vis beschreiben? Wozu sind sie dann "read only"?
-
@paul53
die widget logik beschreibt diese intern.
beispiel: in einem steht die configuration drin, welche senderauswahl im widget angezeigt werden soll.
das widget hat dazu eine eigene oberfläche die der benutzer bedienen kann. das widget schreibt dann json daten. dies sollten die nutzer nicht selbst tun. -
@paul53 sagte in Wozu ist der ack-Flag da?:
@oliverio sagte: Darunter sind auch Datenpunkte, die auf readonly stehen, da der Nutzer diese nicht beschreiben sollte.
Du willst sie trotzdem per Vis beschreiben? Wozu sind sie dann "read only"?
@paul53
die widget logik beschreibt diese intern.
beispiel: in einem steht die configuration drin, welche senderauswahl im widget angezeigt werden soll.
das widget hat dazu eine eigene oberfläche die der benutzer bedienen kann. das widget schreibt dann json daten. dies sollten die nutzer nicht selbst tun. -
@oliverio Also wenn es unbedingt das Widget sein muss 8was ein eher ungewöhnliches Konstrukt ist) brauchst Du wohl das genannte neue vis Feature
Sonst mach option 2
-
Hallo
Habe aktuell wiedermal dieses ack-Flag Problem.
fast 2 Monate war Ruhe.
Heute wieder selbes Problem.web.0 2021-08-24 22:01:47.187 warn Read-only state "alexa2.0.Echo-Devices.G090U5099045059V.Player.mediaProgress" has been written without ack-flag with value "210"Ich hab damals nichts geändert.
Widget ist auch unverändert.[{"tpl":"tplValueString","data":{"oid":"alexa2.0.Echo-Devices.G090U5099045059V.Player.mediaProgressStr","g_fixed":true,"g_visibility":true,"g_css_font_text":true,"g_css_background":false,"g_css_shadow_padding":false,"g_css_border":false,"g_gestures":false,"g_signals":false,"g_last_change":false,"visibility-cond":"==","visibility-val":"","visibility-groups-action":"hide","signals-cond-0":"==","signals-val-0":true,"signals-icon-0":"/vis.0/Buchenweg/lowbattery.png","signals-icon-size-0":0,"signals-blink-0":false,"signals-horz-0":0,"signals-vert-0":0,"signals-hide-edit-0":false,"signals-cond-1":"==","signals-val-1":true,"signals-icon-1":"/vis.0/Buchenweg/lowbattery.png","signals-icon-size-1":0,"signals-blink-1":false,"signals-horz-1":0,"signals-vert-1":0,"signals-hide-edit-1":false,"signals-cond-2":"==","signals-val-2":true,"signals-icon-2":"/vis.0/Buchenweg/lowbattery.png","signals-icon-size-2":0,"signals-blink-2":false,"signals-horz-2":0,"signals-vert-2":0,"signals-hide-edit-2":false,"lc-type":"last-change","lc-is-interval":true,"lc-is-moment":false,"lc-format":"","lc-position-vert":"top","lc-position-horz":"right","lc-offset-vert":0,"lc-offset-horz":0,"lc-font-size":"12px","lc-font-family":"","lc-font-style":"","lc-bkg-color":"","lc-color":"","lc-border-width":"0","lc-border-style":"","lc-border-color":"","lc-border-radius":10,"lc-zindex":0,"visibility-oid":"","html_prepend":"","class":"mdui-blue-glow"},"style":{"left":"354px","top":"503px","color":"#ffffff","width":"78px","height":"37px","text-align":"left","font-style":"normal","font-size":"x-large","z-index":"58","font-weight":"bold","font-family":"RobotoCondensed-Light","text-shadow":"rgba(0, 0, 0, 0.9) 3px 3px 4px"},"widgetSet":"basic"}]
Liegt das Problem an Alexa, an VIS oder an Web?
Was kann ich machen, damit es wieder normal ist? Derzeit wird das Log mit den Meldungen geflutet. -
Servus @homoran!
ich habe diesen Thread zwar gelesen, aber scheinbar doch nicht restlos verstanden. Folgende Situation:
Enigma2 DP
Sobald ich unter Objekten eine Zahl (egal 10, oder 10.0) eingebe,
wird die Lautstärke erfolgreich am Receiver geändert. Gleichzeitig bekomme ich allerdings einen Logeintrag und der übergebene Wert verschwindet im DP:enigma2.0 2021-12-28 09:58:54.682 info State value to set for "enigma2.0.command.SET_VOLUME" has to be type "number" but received type "string"Detto wenn ich in einem Blockly einen Wert setze:
Setze ich den Wert allerdings mit "Bestätigt"
Bleibt der Wert stehen und es kommt auch kein Logeintrag.
Wie kann ich dieses "Bestätigt" in einem Blockly simulieren? Oder bin ich da gedanklich komplett falsch abgebogen?
