Controlling IKEA FYRTUR via PWA results in a 400 response code

I have a several IKEA FYRTUR blinds in my Smart Home. They are set up and working fine, e.g. I can control them over the deCONZ Desktop App.

If I try to control them over PWA / Phoscon Web App, I do see the blind’s brightness slider. When I move the slider, the blind does not move.

Environment

Software Version: 2.19.3, running in a Docker-Container, on a Raspberry PI 4 (arm64)

Steps to reproduce:

(Assuming, a FYRTUR blind is connected and does work in the Phoscon Desktop App)

  1. Open the PWA / Phoscon Web App
  2. Navigate to a FYRTUR blind
  3. Change the brightness of that blind

Actual behavior

The blind does not change its position.

Expected behavior:

The blind moves to the given position.

Technical Notes:

When I change the slider, a PUT request is sent to api/<redacted>/lights/42/state with the following request body:

{
   "on": true,
   "transitiontime": 9,
   "bri": 18
}

The Gateway then responds with a 400 Bad request and the following response body:

[
   {
      "error": {
         "address": "/lights/42/state",
         "description": "parameter, transitiontime, not available",
         "type": 6
      }
   }
]

If I retry the PUT request to api/<redacted>/lights/42/state whilst removing the transitiontime parameter, the blind starts to move. Request Body:

{
   "on": true,
   "bri": 18
}

The Gateway replies with a 200 OK Status and the following Response Body:

[
   {
      "success": {
         "/lights/42/state/lift": 7
      }
   }
]

On a side note:

I stumbled upon this, while trying to create a Scene. This Scene should lateron be assigned to a button of some remote, so that I can recall this scene, including the blind’s position.

When I create a Scene and set the blind’s position manually, as described above, these values seem to be stored somewhere alongside the scene. But the blind’s position does not change when switching scenes (which may be and probably is a different/separate issue/bug)

did you use the ddf from here?

Initially I did not use any DDF, as the blind itself does work and can be controlled with the deCONZ Desktop App - but not with the PWA Web App.

I looked into the following two DDFs (this one from the referenced thread, mentioned above and that one from MR #6110). None of the two solve the problem, I have here: The PWA / Web App still adds the transitiontime parameter, whether I use one of the two DDF or leave them out.

But this helped me to do some testing: When I remove both states (state/bri and state/on), being deprecated in MR #6110, then the Rest API complains about all three parameters, missing. So this does not motivate PWA to use the state/lift property.

Should/Will PWA consider state/lift some time in the future? This parameter is exposed in the DDF of MR #6110 (and the DDF for KADRILJ)

It might be possible, to add a state/transitiontime parameter. But that parameter will never have any functionality, so defining (and publishing?) it seems more than wrong.

hey, I have the same issue and it is pretty annoying. Have to use VNC to control the Fyrtyr blinds as over the Web GUI it is not working. I have tried the DDF and using that, the blinds got unavailable in Web app. Can this be fixed please?

Things going unavailable are 9 / 10 network related problems.

In you case i recommend opening a new topic and Share some logs.

I have the same issue that they guy in initial post, using web UI, when I want to control the blind, i can see in developers console in the network response the same JSON as in initial post with error message:

parameter, transitiontime, not available

This is the GUI bug, should not be sending this parameter. Wouldnt new topic be also duplicate?

Ahh i missed that part.

So using the rest api directly works as intended ?

https://dresden-elektronik.github.io/deconz-rest-doc/

I dont have a REST clien, should I spend time setting one up and figuring out how to do REST request? Issue is obvious, GUI is sending parameter it shouldn’t…

Well if the rest api works its limited to phoscon.
If the gui gets fixed but the api is broken, you have to wait more time.

It’s just because the device (covering) don’t support “transitiontime”, it’s used by light (from the fonction int DeRestPluginPrivate::setWindowCoveringState() )
So for me the API is fine, the problem is more from Phoscon.

tl;dr: Yes, the API works, as intended, but the UI does not.


Fort the record:

  • If I omit transitiontime from the PUT request, then the blinds does move. Therefor I conclude, that the issue resides in the UI - not in the REST API.
  • Also, if I use {"lift":60} as request body to my PUT https://${gateway}/api/${key}/lights/${id}/state request, then the slide does move as well.
    So I conclude, that the UI, if it would use the lift attribute for a blind, that would also already work, as far as the REST API is concerned.

It may be worth noting, that the brightness slider does not move, regardless of whether I use bri or lift as an attribute.


Sorry, I did not find the time necessary to properly test, if adding a transitiontime attribute to the DDF would at least help in working around the current UI’s behavior. Another test would be, removing the bri and on attributes from the DDF, just to test, how the UI reacts to that.

Which level of support is in the PWA Web UI, regarding blinds / window covering devices?
How does the UI determine, which UI components/widgets to display?
→ How far can this be influenced by the DDF?

What can I do to support fixing this?

Thank you very much on the detailed test.

Unfortunately you can’t do anything as its closed source. However , @de_employees or @manup can.

Adding “transitiontime” on the DDF will not help, because phoscon will use the same request, so same problem.
Removing “bri” and “on” can be a good idea yes, it can prevent phoscon use the “transistiontime”, but it can too prevent the device be supported by phoscon (because I don’t think Phoscon use “lift” and “open”)

I removed the bri and on attributes and reloaded deCONZ. The API now lacks these attributes, as expected, but PWA is still trying to set all three parameters ({"on":true,"transitiontime":9,"bri":55}) and now receives three error messages in the response, one for each missing attribute:

[
  {
    "error": {
      "address": "/lights/26/state",
      "description": "parameter, bri, not available",
      "type": 6
    }
  },
  {
    "error": {
      "address": "/lights/26/state",
      "description": "parameter, on, not available",
      "type": 6
    }
  },
  {
    "error": {
      "address": "/lights/26/state",
      "description": "parameter, transitiontime, not available",
      "type": 6
    }
  }
]

This error is correct so far, as these attributes are now no longer defined. But PWA is still treating the blind like a lamp.

Do note, that the API does not expose these attributes when they have been removed from the DDF:

{
  "etag": "<redacted>",
  "hascolor": false,
  "lastannounced": null,
  "lastseen": "2023-01-18T18:12Z",
  "manufacturername": "IKEA of Sweden",
  "modelid": "FYRTUR block-out roller blind",
  "name": "Rollo WZ Rechts",
  "state": {
    "lift": 100,
    "open": false,
    "reachable": true
  },
  "swversion": "2.3.088",
  "type": "Window covering device",
  "uniqueid": "<redacted>"
}

Now I did try to add the transitiontime attribute, as hinted in the following addition to this DDF, though that did not help, either (most probably, since there is no such attribute in the Available items UI in deCONZ’s DDF Editor):

{
...
   "subdevices": [
      {
         "type": "$TYPE_WINDOW_COVERING_DEVICE",
         "restapi": "/lights",
...
         "items": [
...
            {
               "name": "state/reachable"
            },
            {
               "name": "state/transitiontime",
               "parse": {
                  "fn": "none"
               },
               "read": {
                  "fn": "none"
               },
               "deprecated": "2020-04-08"
            }
         ]
      },
      {
         "type": "$TYPE_BATTERY_SENSOR",
         "restapi": "/sensors",
...
      }
   ],
   "bindings": [
...
   ]
}

So no luck on this End.


What else can I try?
Is there any other type of blind out there, that PWA treats as a blind (instead of a light)?

IDK how phoscon is working, but not possible making a better device json that the one you have.

No, as i mentioned, you can’t do anything. Phoscon is the issue here.

So will Phoscon fix this?

Our problem:We have the Kardyl roller blind on site to test. This works without any problems. The Fyrtur should not really be technically different, which is why we are somewhat at a loss here.
I have passed the case on to our development. There will be feedback.

Thanks for the reply and looking forward to the feedback. I think the problem is pretty clearly described in previous posts and it is also clear how to fix this even without testing on Fyrtur directly.

I currently have to use VNC to control the blinds, which takes time and is really annoying. Doing this for months, since no fix yet.

I have a few FYRTUR - but I don’t have a blind option in Phoscon. Why?