Done.
I got the same message.
Thanks for the log. I can see something is not correct as there are null commands being sent. That gives me a good starting point to track it down.
1 Like
I think I have tracked it down. I am guessing that when you mentioned the MY position you were referring to the idle / stop button on the screen that has the Up / Idle / Down buttons?
I found that the stop button was not being implemented and therefore sending a null command. I have now mapped that in to the Somfy Stop command.
What you should also find, on the next screen is the MY POSITION button. This will send the shutter to the pre-programmed MY position. There is also a flow action card to do the same.
I think I remember the stop button having a dual action of Stop or MY position when I took over the app. But that was causing problems, as the app can not detect for sure if the cover is actually moving due to delays in the communications. So, it was unpredictable if the button would stop the cover or move it to the MY position. Therefore, I split the two functions to separate buttons for safety.
To summarize, you will need to change any flows that want to move to the MY position so they use the new ‘Move to MY Position’ action card. Also if you want to manually move to the MY position using the app, then you will need to tap on the new ‘MY POSITION’ button.
Sorry for the confusion I caused with that change.
1 Like
It was probably dual action since that is how the remotes work. However, they are 1-way (almost certain), so the shutter must be interpreting itself if it should stop, or go to MY.
1 Like
At least I don’t get the error message anymore. Thank for the last update.
If the Stop button is meant for stop only and not for MY position isn’t it nice the make a motion next to it “Stop only”?
What you say, but now it only works as a stop button. (Since last update)
If that is the case then the middle button in the app should do the same. However, from the API, ‘stop’ and ‘my’ are separate commands, so it possibly works differently than the remote.
All my blinds and curtains are RTS and they have a seperate MY button. Maybe because they have no read back capability.
Unfortunately I have no control over the display format for that screen as it is the way Homey displays that capability.
1 Like
@Geurti Come on, how hard can it be. There is also no “up only” and “down only” and the circle icon does not mention MY in any way. People have a separate my position page with a button. From my point of view no need to mention on the page it’s “stop only”. The good thing is you could automate the things you want. Close / open / ventilation (my position) with a flow.
1 Like
I was reading up on this topic because I’ll be buying a Connexoon a few months from now, when I get two IO blinds. Currently I do not use this app yet, but do own several RTS screens.
The separation of the functions on the stop button, especially for RTS is in my opinion a very good thing. My Telis RTS remote has the double function button (it does not mention MY). I currently use the Somfy RTS app which emulates the remote.
Because there’s no two way communication, Homey often had the button in the wrong position, depending on what Homey did last. This position was often wrong, when the screen was operated outside Homey’s knowledge though the physical remote.
I too had then problems that Homey would not execute commands all the time, because the button in Homey was already in the position I wanted the screen to go (and the screen was not in that position anymore). So my solution was to have Homey always put the button in the Stop position, some 40 seconds after the up or down command from Homey.
But that didn’t work, because the screen would sometimes stop too soon, or go to the My position if it happened too late. So in the end I decided to remove the my position from the screen, to force the middle button to do - you guessed it - Stop only.
If I decide to buy a Tahoma instead of a Connexoon and link my RTS screens to Tahoma as well, would that alleviate the problems I describe and allow me to use the My position again, or do I need similar workarounds if the screens are operated though a physical remote outside the view of Homey / Tahoma?
The app does indeed separate the stop and MY buttons for RTS.
It also clears all the buttons once the command has been acknowledged by the Tahoma API (obviously not the screen). Therefore the buttons should always be available to perform any action at any time, even if the screen has been moved by the remote.
In short I adapted the app to be as flexible as possible for RTS screens as I had the same issue with the RTS app. Also I found that Tahoma was much more reliable at sending the commands to the screens that are furthest away.
Hope that makes sense.
1 Like
That is certainly a reason to look at Tahoma again. Do you know if the screens also work well with Google Home? I had issues that both up and down voice commands executed down. I circumvented that with Google Routines.
I think so, but I use Alexa all the time. They work fine with that.
Since the last update, there is no issue with the door sensor and all status updates are fully captured.
Thank you for this update, Adrian.
1 Like
Screens work good together with google home.
I have connexoon io and all iomotors (since velux is also io and i only wanted 1 system/hub) i can ask to open/close every screen by itself. If i add x% it opens/closes that amount of the screen(IO only i guess). And if i say a open/close livingroom it works on all windows in my livingroom.( i made a new room under my livingroom so i can also voicecontrol the entire southside at once without the other screens reaction).
The only error i have is when i say open/close everything. Then it says there is a problem with 19 devices(all my motors). However some screens react immediatly, some after 2 minutes and some ignore it. Always different combinations. I made a routine in google home to activate a flow in homey that opens/closes all (one of my 4 scenarios in connexoon)to avoid this. You can force connexoon to have more scenarios also(found out by accident that if the homeyapp is connected and you save your scenarios they are saved to homey. If you change your username in the connexoonapp you can save 4 different scenarios. Homey remembers all 8. Change username again and you have 12 scenarios…
1 Like
Hi Adrian, smth happened at night. The blinds do not react on flows. They react to device operation in tiles but do not report the status correctly. Shall i send you the log? Thank you
If you are having problems after the v5 update then check the following:
- The time on your Homey in Settings - General - About. Some users have found the time is an hour out and that seems to stop timed flows from working. On mine the date field was not even shown. If it is wrong then reboot Homey. After a reboot my time is now shown and correct, but not sure if it has fixed the flow problem.
- Check in the Somfy app configuration to make sure polling is enabled.
I don’t know why the release update has caused me problems as I was running the last RC and it had been working. According to the update page, my update to the release version was only 455 Bytes, so I’m guessing it was just the version number change. However, it did seems to mess up my Homey a little bit.
Maybe with so many Homeys all updating at the same time it caused some other connection issue when it booted up.
Of course I will keep monitoring my flows to make sure they are working again and if I find anything I will post back.
Exactly I was running latest v5 RC and only few bytes of update to stable v5. I will thry your suggestion. Thanks man
Edit: seems again working after homey restart
Hi @Adrian_Rockall . I have a question on the Lock State variable. I know it is linked to, in my case, the Somfy Aeolus wind sensor on my awning. When the sensor is triggered, Lock State is updated with value “wind”. However, when the wind alert is lifted in the Somfy app, nothing changes in the Lock state variable. It keeps saying “wind” and is never actually changed, only the time of the last update. This causes any flow that is triggered by a “lock state change” not to be triggered, since the value of “Lock state” is never actually changed, just updated with the same value I guess.
Am I doing something wrong in my flow management here, or is this a bug?
Sounds like a bug. Could you send me the Device log when it’s set in the Somfy app and one when it’s not.
I appreciate it’s probably not possible to actively set and reset it.
I have looked through all the logs that I have and none have it reported. So I’m wondering if it only appears when it’s set.
Just out of interest what polling Interval do you have set?
I would expect that the event notices should say when it’s been cleared, but if the Interval is too long the session closes and the notices are lost.
I have found there is a core:PriorityLockTimerState that is set 0 in all the logs, so maybe that indicates there is no lock state active. Hopefully a log when it is set will indicate that.
1 Like
