Blind position doesn't work

[MubiTec]

I configured a blind with devices adapter When I put a new position in data point SET it works fine. When I try to do it with the widget nothing happens With the up and down buttons I can send it up and down, but to put it on a direct position it do not work. Adapter version 1.04

[Streit187]

Also for others: https://forum.iobroker.net/topic/49062/material-jalousie-nur-komplett-auf-oder-zu/

[ben-efiz]

Found this issue as i have a similar one. Using adapters Material 1.1.2 and KLF-200 1.0.1. I get the following errors when using the down button to close

klf200.0 | 2022-03-13 23:47:00.892 | warn | Terminated (JS_CONTROLLER_STOPPED): unhandled promise rejection
-- | -- | -- | --
klf200.0 | 2022-03-13 23:47:00.888 | error | Unhandled promise rejection detected. reason: {}, promise: {}
klf200.0 | 2022-03-13 23:47:00.883 | error | Position value out of range.
klf200.0 | 2022-03-13 23:47:00.882 | error | Error: Position value out of range. at convertPosition (/opt/iobroker/node_modules/klf-200-api/dist/KLF200-API/GW_COMMAND.js:225:15) at Product.setTargetPositionAsync (/opt/iobroker/node_modules/klf-200-api/dist/products.js:475:117) at PercentageStateChangeHandler.<anonymous> (/opt/iobroker/node_modules/iobroker.klf200/build/util/propertyLink.js:161:43) at processTicksAndRejections (internal/process/task_queues.js:95:5)
klf200.0 | 2022-03-13 23:47:00.879 | error | unhandled promise rejection: Position value out of range.
klf200.0 | 2022-03-13 23:47:00.875 | error | Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().
web.0 | 2022-03-13 23:47:00.850 | warn | State value to set for "klf200.0.products.1.targetPosition" has value "255" greater than max "100"

The reason here is obviously that instead of 100 the targetPosition 255 is send which crashes the klf200 adapter. Not sure where the 255 is coming from as the KLF-200 defines 100 as max value here and Material's SmartBlinds should process that here. It seems though its using the state's max value?

{
  "type": "state",
  "common": {
    "name": "state",
    "role": "value",
    "type": "number",
    "read": true,
    "write": false,
    "min": 0,
    "max": 255,
    "desc": "Operating state",
    "states": {
      "0": "NonExecuting",
      "1": "Error",
      "2": "NotUsed",
      "3": "WaitingForPower",
      "4": "Executing",
      "5": "Done",
      "255": "Unknown"
    }
  },
  "native": {},
  "from": "system.adapter.klf200.0",
  "user": "system.user.admin",
  "ts": 1647185974054,
  "_id": "klf200.0.products.1.state",
  ...
}

While i can see above error logs when using down button there is no event at all for the direct position (would have expected also errors for 101 - 255 aka 39% - 100%) which leads me to the assumption that target position is not called at all (so not an issue of the KLF adapter otherwise i would see the error). So i assume SmartBlinds's setValue is not called when selecting granular steps.

[Apollon77]

uuuhhhh interesting case. In fact (ignoring the "states" list) the material does right ... it "sees" min/max and then calculates the value based on min/max for open/close.

So on one hand KLF adapter should not send min/max if not the whole range is allowed, so the min/max is making material do wrong assumstions. So try to remove min/ax from the objects ...

But in fact on the other hand because "write=false" material should not try to write that state at all - and also klf should never accept a write on this state because it defined it is not writeable ...

SO honestly there are many starnge things coming together here ... starting with a missleading object definition?!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within the next 7 days. Please check if the issue is still relevant in the most current version of the adapter and tell us. Also check that all relevant details, logs and reproduction steps are included and update them if needed. Thank you for your contributions. Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn nicht innerhalb der nächsten 7 Tage weitere Aktivitäten stattfinden. Bitte überprüft, ob das Problem auch in der aktuellsten Version des Adapters noch relevant ist, und teilt uns dies mit. Überprüft auch, ob alle relevanten Details, Logs und Reproduktionsschritte enthalten sind bzw. aktualisiert diese. Vielen Dank für Eure Unterstützung.

[Streit187]

Not solved!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within the next 7 days. Please check if the issue is still relevant in the most current version of the adapter and tell us. Also check that all relevant details, logs and reproduction steps are included and update them if needed. Thank you for your contributions. Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn nicht innerhalb der nächsten 7 Tage weitere Aktivitäten stattfinden. Bitte überprüft, ob das Problem auch in der aktuellsten Version des Adapters noch relevant ist, und teilt uns dies mit. Überprüft auch, ob alle relevanten Details, Logs und Reproduktionsschritte enthalten sind bzw. aktualisiert diese. Vielen Dank für Eure Unterstützung.

[Streit187]

Reopen

[ahhkoch]

Solution? It is marked as "fixed" - where can i find the fix?