ZigBee und send_payload ... ging genau EIN Mal
-
Hallöchen. Mein ZickenBienenVolk hat mal wieder Zuwachs bekommen. Zwei Außenrollos auch CN, mit diesem Antrieb:
https://www.zigbee2mqtt.io/devices/WM25L-Z.htmlZigbee Adapter 1.10.3
Angelernt, alle Objekte sind da, alles wie im Bilderbuch zack zack. Wenn sie per mitgelieferter Fernbedienung gesteuert werden aktualisieren sie brav alle Werte sobald sie die jeweilige Fahrt stoppen. Während sie fahren senden sie keine Messages. Soweit so gut, alles prima.
Jetzt will ich sie steuern. Dazü müsste ich gem. der Seite oben einen dieser Strings in
zigbee.0.{device-ID-here}.send_payloadschreiben.{"state": "OPEN"} {"state": "CLOSE"} {"state": "STOP"} {"position": VALUE}(Mit Value 0=Stoff oben, offen; 100=Stoff unten, geschlossen; oder etwas dazwischen.)
Habe das manuell probiert, indem ich in das Objekt die Zeile mit "position" oben inkl. der {} kopiert und den Wert auf 50 (nur die Zahl) gesetzt habe. Den Haken bei "Bestätigt" hatte ich nicht gesetzt. Habe also nur den String editiert (und das Einfabefeld auch auf "String" gelassen) und dann CTRL+Enter gedrückt. Und Zack, das ding ist auf 50% gefahren.
Gut, wa?
Tja, denkste... das hat GENAU EIN MAL funktioniert. Egal was ich danach dort eingetragen habe, es passiert "nüscht".
Habe den Wert zwischenzeitlich auch mal komplett geleert.Im Log erscheint dies (von unten nach oben lesen für die richtige Reihenfolge; die "----" zur besseren Lesbarkeit ergänzt)
Stack trace for failed (Timeout - 57809 - 1 - 9 - 258 - 11 after 10000ms),Timeout - 57809 - 1 - 9 - 258 - 11 after 10000ms: Error: ZCL command 0x0ceff6fffea851cb/1 closuresWindowCovering.goToLiftPercentage({"percentageliftvalue":50}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Timeout - 57809 - 1 - 9 - 258 - 11 after 10000ms) at Object.start (/opt/iobroker/node_modules/zigbee-herdsman/src/utils/waitress.ts:63:23) at ZStackAdapter.sendZclFrameToEndpointInternal (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:497:47) at Queue.execute (/opt/iobroker/node_modules/zigbee-herdsman/src/utils/queue.ts:35:20) at Request.send (/opt/iobroker/node_modules/zigbee-herdsman/src/controller/helpers/request.ts:79:20) at Endpoint.zclCommand (/opt/iobroker/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:756:28) at Endpoint.command (/opt/iobroker/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:587:24) at Object.convertSet (/opt/iobroker/node_modules/zigbee-herdsman-converters/src/converters/toZigbee.ts:611:13) at /opt/iobroker/node_modules/iobroker.zigbee/main.js:754:36 ---- Send command to 0x0ceff6fffea851cb failed with no error code (Timeout - 57809 - 1 - 9 - 258 - 11 after 10000ms) ---- Stack trace for failed (Timeout - 57809 - 1 - 9 - 258 - 11 after 10000ms),Timeout - 57809 - 1 - 9 - 258 - 11 after 10000ms: Error: ZCL command 0x0ceff6fffea851cb/1 closuresWindowCovering.goToLiftPercentage({"percentageliftvalue":50}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Timeout - 57809 - 1 - 9 - 258 - 11 after 10000ms) at Object.start (/opt/iobroker/node_modules/zigbee-herdsman/src/utils/waitress.ts:63:23) at ZStackAdapter.sendZclFrameToEndpointInternal (/opt/iobroker/node_modules/zigbee-herdsman/src/adapter/z-stack/adapter/zStackAdapter.ts:497:47) at Queue.execute (/opt/iobroker/node_modules/zigbee-herdsman/src/utils/queue.ts:35:20) at Request.send (/opt/iobroker/node_modules/zigbee-herdsman/src/controller/helpers/request.ts:79:20) at Endpoint.zclCommand (/opt/iobroker/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:756:28) at Endpoint.command (/opt/iobroker/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:587:24) at Object.convertSet (/opt/iobroker/node_modules/zigbee-herdsman-converters/src/converters/toZigbee.ts:611:13) at /opt/iobroker/node_modules/iobroker.zigbee/main.js:754:36 ---- Send command to 0x0ceff6fffea851cb failed with no error code (Timeout - 57809 - 1 - 9 - 258 - 11 after 10000ms) ---- target: {"_events":{},"_eventsCount":0,"_maxListeners":100,"deviceID":514,"inputClusters":[0,1,3,4,5,258],"outputClusters":[3,25],"profileID":260,"ID":1,"clusters":{"closuresWindowCovering":{"attributes":{"currentPositionLiftPercentage":0}},"genBasic":{"attributes":{"modelId":"WM25/L-Z","manufacturerName":"Smartwings","powerSource":0,"zclVersion":8}},"genPowerCfg":{"attributes":{"batteryPercentageRemaining":100}}},"deviceIeeeAddress":"0x0ceff6fffea851cb","deviceNetworkAddress":57809,"_binds":[{"cluster":1,"type":"endpoint","deviceIeeeAddress":"0x00124b0009d80909","endpointID":1},{"cluster":258,"type":"endpoint","deviceIeeeAddress":"0x00124b0009d80909","endpointID":1}],"_configuredReportings":[],"meta":{},"pendingRequests":{"sendInProgress":false,"ID":1,"deviceIeeeAddress":"0x0ceff6fffea851cb"}} ---- entity: 0x0ceff6fffea851cb {"type":"device","device":{"_events":{},"_eventsCount":0,"_maxListeners":100,"ID":12,"_endpoints":[{"_events":{},"_eventsCount":0,"_maxListeners":100,"deviceID":514,"inputClusters":[0,1,3,4,5,258],"outputClusters":[3,25],"profileID":260,"ID":1,"clusters":{"closuresWindowCovering":{"attributes":{"currentPositionLiftPercentage":0}},"genBasic":{"attributes":{"modelId":"WM25/L-Z","manufacturerName":"Smartwings","powerSource":0,"zclVersion":8}},"genPowerCfg":{"attributes":{"batteryPercentageRemaining":100}}},"deviceIeeeAddress":"0x0ceff6fffea851cb","deviceNetworkAddress":57809,"_binds":[{"cluster":1,"type":"endpoint","deviceIeeeAddress":"0x00124b0009d80909","endpointID":1},{"cluster":258,"type":"endpoint","deviceIeeeAddress":"0x00124b0009d80909","endpointID":1}],"_configuredReportings":[],"meta":{},"pendingRequests":{"sendInProgress":false,"ID":1,"deviceIeeeAddress":"0x0ceff6fffea851cb"}}],"_ieeeAddr":"0x0ceff6fffea851cb","_interviewCompleted":true,"_interviewing":false,"_lastSeen":1722520859113,"_manufacturerID":4098,"_manufacturerName":"Smartwings","_modelID":"WM25/L-Z","_networkAddress":57809,"_powerSource":"Mains (single phase)","_type":"EndDevice","_zclVersion":8,"_linkquality":60,"_skipDefaultResponse":false,"_lastDefaultResponseSequenceNumber":53,"_pendingRequestTimeout":0,"meta":{"configured":-245136374}},"mapped":{"zigbeeModel":["WM25/L-Z"],"model":"WM25L-Z","vendor":"Smartwings","description":"Roller shade","fromZigbee":[{"cluster":"closuresWindowCovering","type":["attributeReport","readResponse"],"options":[{"name":"invert_cover","label":"Invert cover","access":2,"type":"binary","property":"invert_cover","description":"Inverts the cover position, false: open=100,close=0, true: open=0,close=100 (default false).","value_on":true,"value_off":false}]},{"cluster":"genPowerCfg","type":["attributeReport","readResponse"]}],"toZigbee":[{"key":["state"]},{"key":["position","tilt"],"options":[{"name":"invert_cover","label":"Invert cover","access":2,"type":"binary","property":"invert_cover","description":"Inverts the cover position, false: open=100,close=0, true: open=0,close=100 (default false).","value_on":true,"value_off":false}]},{"key":["scene_store"]},{"key":["scene_recall"]},{"key":["scene_add"]},{"key":["scene_remove"]},{"key":["scene_remove_all"]},{"key":["scene_rename"]},{"key":["read"]},{"key":["write"]},{"key":["command"]},{"key":["reset"]},{"key":["zclcommand"]}],"meta":{"battery":{"dontDividePercentage":true},"coverInverted":true},"exposes":[{"type":"cover","features":[{"name":"state","label":"State","access":3,"type":"enum","property":"state","values":["OPEN","CLOSE","STOP"]},{"name":"position","label":"Position","access":7,"type":"numeric","property":"position","description":"Position of this cover","unit":"%","value_max":100,"value_min":0}]},{"name":"battery","label":"Battery","access":1,"type":"numeric","property":"battery","description":"Remaining battery in %, can take up to 24 hours before reported","category":"diagnostic","unit":"%","value_max":100,"value_min":0},{"name":"linkquality","label":"Linkquality","access":1,"type":"numeric","property":"linkquality","description":"Link quality (signal strength)","category":"diagnostic","unit":"lqi","value_max":255,"value_min":0}],"options":["[Circular]"]},"endpoint":"[Circular]","endpoints":"[Circular]","name":"0x0ceff6fffea851cb"} ---- publishFromState : 0x0ceff6fffea851cb [{"stateDesc":{"id":"position","prop":"position","role":"state","type":"number"},"value":50,"index":0,"timeout":0}] ---- Calling publish to state for "0ceff6fffea851cb" with [{"stateDesc":{"id":"position","prop":"position","role":"state","type":"number"},"value":50,"index":0,"timeout":0}] ---- publishToDevice called with {"device":"0ceff6fffea851cb","payload":{"position":50}}Was mache ich falsch?
Und: wie oben erwähnt beim ersten Versuch als "String" gesendet. Danach stand das Objekt bei jedem weiteren Versuch von sich aus als "JSON" da. Auch wenn ich via NodeRed in das Objekt schreibe steht es danach auf "JSON". Ist es wichtig, ob das schreiben als "String" oder "JSON" passiert? Wenn es "String" sein muss (was ich bei jedem händischen Versuch eingestellt habe), wie würde ich das aus NodeRed heraus sicher stellen?Schöne Tage euch, und schon mal Dank für eure wertvolle Zeit!
-
@fiddle sagte: "String" oder "JSON"
JSON ist ein String.
-
@paul53 sagte in ZigBee und send_payload ... ging genau EIN Mal:
@fiddle sagte: "String" oder "JSON"
JSON ist ein String.
Ok...dann sollte das ja egal sein (nur, warum gibt es dann beide Optionen in der Maske zum Setzen des Objektes?).
Bleibt die Frage im "Hauptsacheverfahren"... warum passiert nix
?Edit: Gerade nochmal probiert.
{state}:{OPEN}und "CLOSE" und "STOP" hat gerade 2-3 Mal funktioniert, dann wieder nicht mehr. "position" mit Zahlenwert wiederum nicht. Und die anderen jetzt auch wieder nicht mehr.... strange. -
@fiddle Deinem Log-Auszug fehlen die Zeitstempel. Das macht es schlechter lesbar.
Die Meldung
Send command to 0x0ceff6fffea851cb failed with no error code (Timeout - 57809 - 1 - 9 - 258 - 11 after 10000ms)deutet darauf hin das das Gerät nicht antwortet.
Allerdings stell ich mir die Frage warum du das Device über
send_payloadsteuerst. Du müsstest eigentlich die StatesStateundPositionhaben, in die du den Ziel-Zustand hinein schreiben kannst.Zeig doch mal die Objekte des Geräts.
A.
-
@asgothian bin jetzt unterwegs, daher nur als Text: Die genannten Objekte habe ich, die bekommen auch schlüssige Werte wenn die Geräte ein update von sich aus senden.
Habe ich die Instruktionen auf der im ersten Post verlinkten Seite falsch gedeutet? Da steht ja, dass man diese Zustände eben nicht "schreiben" ="setzen" kann, sondern das eben über diesen (Um)Weg machen muss. Hatte meine ich anfangs mal aus Gewohnheit versucht da was reinzuschreiben bevor ich oben Verlinktes gelesen hatte, hatte meine ich nicht funktioniert, daher dann dieser Weg "wie er im Buche steht" . Kann Samstag Abend wieder testen... -
Hab' da gestern noch weiter mit rumgespielt. Scheinbar sind die Dinger etwas unzuverlässig erreichbar, obwohl die Signalstärke >60 ist und sie auch regelmäßig ihren Status melden. Kommandos senden geht mal mehrmals nacheinander, dann wieder reagieren sie nicht.
Kommandos Senden geht tatsächlich auch über beschreiben der Objekte für "State", "Position", oder eben über den oben genannten send_payload weg. Bei dem bleibe ich, denn nur so kann ich über die eigentlichen Objekte zuverlässig den tatsächlichen Stand der Dinger rückgemeldet bekommen. Schreibe ich direkt in State oder Position, dann steht da ja der Wert drin den ich haben will - aber nicht der, den die Teile tatsächlich erreicht haben. Daher macht es schon Sinn diese Objekte als "read only" zu betrachten (für mich).
Eine Seltsamkeit dieser Dinger, falls die mal einer verbaut: Man kann ihnen beibringen wie sie "close" bzw "100%" interpretieren bzw. "meinen" sollen. Dafür gibt es die Option
invert_cover. Entweder entspricht- "open"=100% Stoff eingerollt, "close"=0% Stoff eingerollt (=alles abgerollt);
- "open"=0% (alles abgerollt), "close"=100% (alles eingerollt).
Kann man über die Fernbedienung an den Dingern umschalten.
Ich habe für mich die Logik gewählt: "100% eingerollt = open = wie ein Fensterladen: Offen heißt, ich lasse 100% Licht ins Zimmer, kann 100% raus gucken".Aber das ist nicht der springende Punkt. Egal welche Einstellung man setzt, man muss den Dingern scheinbar immer den "State" abverlangen, den man eigentlich schon HAT. Also, das Ding sagt in seine, "State" Objekt: ich bin "CLOSED". Wenn ich nun "OPEN" erreichen will, muss ich trotzdem CLOSED als Befehl senden, nicht OPEN wie man erwarten würde. Und umgekehrt. Und das, egal wie ich obige "Interpretation" einstelle. Sehr seltsam...aber funktioniert.
Nunja, scheinbar nutzbar wenn man im Normalfall halt einmal schließt, und viel später wieder öffnet. Werde beobachten, ob das hinreichend zuverlässig läuft an Sonnentagen.
-
@fiddle sagte in ZigBee und send_payload ... ging genau EIN Mal:
Kommandos Senden geht tatsächlich auch über beschreiben der Objekte für "State", "Position", oder eben über den oben genannten send_payload weg. Bei dem bleibe ich, denn nur so kann ich über die eigentlichen Objekte zuverlässig den tatsächlichen Stand der Dinger rückgemeldet bekommen. Schreibe ich direkt in State oder Position, dann steht da ja der Wert drin den ich haben will - aber nicht der, den die Teile tatsächlich erreicht haben. Daher macht es schon Sinn diese Objekte als "read only" zu betrachten (für mich).
An dieser Stelle ist der Status “bestätigt” interessant. Wenn du einen wert in den state schreibst, dann als “Vorgabe”, sprich umbestätigt mit dem
steuereBaustein (Blockly) oderack=false(JS). Wenn der Adapter diesen Befehl abgearbeitet hat und vom Gerät eine Rückmeldung bekommt wird diese mit Bestätigung geschrieben. Über den Status kannst du also feststellen ob der wert von Dir oder vom Adapter kommt. Nur so zur Info. Wenn du mit demsend_payloadhin kommst dann ist das auch gut.A.
-
@asgothian Danke für die Erklärung zu "ACK". Ich nutze NodeRed, vermutlich lässt sich das da auch umsetzen, habe ich aber noch nirgends gebraucht in meinen diversen Bastellwerken...
Zu meinem Problem hier: langsam habe ich eher die Antenne des einen Antriebs im Verdacht. Schlechte Verbindung zu einer Dose, die dann weiter verteilt, während der andere Antrieb (in absolut ähnlicher Montageposition) satte Verbindung zu einer Dose hält, die an dem "unzuverlässigen" viel näher dran ist. Muss ich mal weiter fummeln... die über kreuz montiert hängen... reklamieren... mal sehen. Liegt jedenfalls wohl nicht am Adapter.
-
@fiddle sagte in ZigBee und send_payload ... ging genau EIN Mal:
Danke für die Erklärung zu "ACK". Ich nutze NodeRed, vermutlich lässt sich das da auch umsetzen, habe ich aber noch nirgends gebraucht in meinen diversen Bastellwerken...
In der iobroker-out Node:
Type command = ACK false
Type value = ACK trueSteuern über Datenpunkte eines Adapters immer mit command. Value nur für speicherung eigener Werte in 0_userdata.0
