I have previously setup a number of somfy blinds (MSR: 026E-5253-5A31) to work with smartthings and it went fantastic. Now three months later the blinds still respond to open, close, and to specific set percentage, but not to the preset values. Using the Somfy remotes, I can see the preset is still held in the blind, it just does not work through smartthings. When I try to use the preset, it tells me “Couldn’t connect to [device name]. Try again later.”
It has been like this for a few days now, tried rebooting the hub but problem persists.
Hey. Pretty sure this is on our end and I think I know what caused it. Thanks for bringing it to our attention. I’ll get to work on it. It will probably be a little while until it gets fixed, though.
Hi. I’m glad I found this thread, because I also have 13 blinds, that stopped to work with “preset” function. As a temporary workaround in my Webcore automations, I have used “level” adjustment to simulate preset. But the property “Preset position” just went gone from the DTH capabilities list in Webcore.
Hi Steven,
So far You did not came back with any update, and recently Domoticz-Server Smart app creator and maintainer, found a work around for the issue I have reported.
Check his comment
and also this code diff:
Hope this is a confirmation of the issue I have reported. Could You explain what is the next step You would like to archive in this circumstances?
How should I call now “preset” position in Webcore, for example. Will tere be furtner changes?
First, apologies about the execution of this change. The execution has been annoyingly haphazard, as have the reasons for it… (That is about all I can really comment on the “back end” pieces and my feelings about it at this time, I’m afraid.) I’ll have a post that outlines some other capability changes (some we have been requested to implement, and some that are still being implemented). This change was meant to be a little less intrusive, but that isn’t how it worked out.
Anyway… The presetPosition command was moved into the Window Shade Preset capability as it was argued that some window shades may not support a presetPosition. Regardless of where it might make sense (there are definitely different correct answers for different avenues of thought), this was needed so that we could mark the Window Shade capability as “live” from “proposed” for use elsewhere. So, with that, Window Shade, as it is “live” now, will no longer have anything removed or moved from it (though it could have things added at a later date). I’ll further explain this in an upcoming post – including plans we have for capabilities, changes that are coming in the near future, and semantics amongst things like “proposed” and “live” and “deprecated” and what those mean and anything else that makes these processes more transparent and provide fore-warning instead of apologizing (something that myself and @tpmanley have been pushing for).
So…
For now, presetPosition might not show up in parts of the new SmartThings app yet and I am working to fix that (there are really weird nuances for that).
As far as using presetPosition in the Groovy world, it should go back to working for custom device handlers if you define “Window Shade Preset” as a capability of the device (that way presetPosition will be treated as a command and any data returned from it will be acted on properly – like, actually making the window treatment go to the preset position ). Just after rolling the change to the capability out we did update device handlers in the SmartThingsPublic repository (as well as any other WWST integrations), so those should be working fine.
As a side note: I don’t have a strong understanding of the backend for Webcore, so I can’t really assist with that. I will reach out to @adrian97c about this.
Anyway, enough with this essay. I’ll have more to come in a bit.
I’m hoping to get a client side fix for this worked in to the plugin – however, I don’t actually know specifically when it would be in (I don’t have any control over that).
Strange that You guys are expecting something. My understanding is that everything is fixed already.
Both Martin and Donald explained it above.
If You still have some issues, please explain in details. Maybe I or others will be able to help.
I believe the only part that isn’t really fixed is the SmartThings app part. I saw some indications that there would be a client fix in next month so that the button on the device page would work.
@all: I have Somfy blinds, connecting to Domoticz through RFXtrx433E, and them Domoticz promote them to SmartThings via “Domoticz-Server Smart app”. As You can imagine, there could have been many sources of failure in this instalation, and aiming what causes that “preset position” is not working could not be trivial.
So again, what is the background? How Your set up is configured? You must guys make this transparent in order to get help.
I pinged Adrian some time back. I am going to check in with him again.
Small update: It looks like the fix for the SmartThings App part should be released soon. I have been using it on some blinds here at my desk and things appear to be working.
@bgalfond I’m going through and making sure that we haven’t missed any devices in this update, and I would like to check, what is the device handler that your blinds are paired as?
This seems to still be an issue for my comfy smart blinds. They are the homedepot bali brand. They worked in the past and now the preset button is just a spinning indicator in the app that never goes away.
Edit:
I guess this issue is not monitored anymore. I did check to make sure the smartthings app was updated already. Other than not being able to use the preset button in the app and the continuing spinning icon, everything’s else is woking.
Have this issue been remedied on the front end ST new App? I see only level and open as options in classic app yet the preset is a tile in the device (shade) itself. Can you please provide when preset will properly function in both apps as no routines/automations work on preset as the option does not exist.
). Just after rolling the change to the capability out we did update device handlers in the SmartThingsPublic repository (as well as any other WWST integrations), so those should be working fine.