Fail 
nothing happen. But it is also perfect like that!.
Thank you verry much for your patience and good work!
1 Like
Hi adrian,
I am using your app for some time now and everything worked great, but i only used position to 0 or 100, and open/close.
Yesterday i created a few flows that send my shutters to a tag (just the number 23) wich is the position light can enter, but heat cant. It worked during testing, but sometimes it didnt. This morning it refused again an i got this message during a test
Could it have something to do with polling? My settings are like this
And something less important(languagerelated), when i set status i have the following screen:
Omhoog means up, omlaag means down, and i suspect stil means stop? Stil has 2 meanings in dutch, one that means no movement, but also silence.
The error suggest the value of the tag is to big. It looks like it is being generated by the Homey setCapability function or the flow validation. The value should be between 0 and 1 as that is what Athom have defined to represent 0 to 100%.
Alleight ill change it to 0.23 then and let you know how it goes, strange it works at certain times then.
Edit: tested virtual and it seems to work,?ill check when i get home from work if it physicly did everything fine too.
I toyed arround yesterday with âgo to tagâ and âgo to position 23â. Perhaps go to 23 works and when its a tag it should be 0.23? Thats the only thing i can think off since the last thing i did yesterday was change all 23âs to the tag for quick adjustement in the future.
Will the new tahoma switch work with this app?
It strange the way Homey works with cover positions. The values you enter manually are converted from 0 - 100% to 0 - 1. But as the tags feed the numbers directly to the function they bypass that conversation.
The frustrating thing is Somfy takes values in the range 0 - 100 so I have to convert them all back again.
1 Like
Unfortunately I have no idea. I havenât seen one or heard of anyone using one yet.
ok thanks
all i know its 200⏠so a lot cheaper than the tahomabox. but not cheap enough to buy without knowing it will work with homey or not. so iâm not going be the testcase 
1 Like
Hello Adrian,
I see when I open one of my screens that itâs âpercentage openedâ is displayed.
But while making a flow I can only choose for âstatusâ or âthe screen is movingâ in the âandâ section.
Is it possible to add the possibility to choose something like: âscreen is (not) open for xx %â
Thanks in advance.
I donât have this type blinds but this should be possible already by testing the dim level using logic
For example
1 Like
You can use the logic cards and the tag for the screens position. E.g.
Then for ⌠select the position tag for the required screen from the list and then enter the number. The only thing to note it the position value in a tag is the native Homey value so in the range of 0 to 1, therefore 0.5 = 50%.
1 Like
I just read this, and remembered that I meant to contact you (@Adrian_Rockall ) about issues I have in this regard. I too wanted something similar for my IO rollershades. Basically I want one trigger wnen fully opened, and one when put at any other position than fully open. The state actions wonât cover all cases, eg. for putting the shade in the MY position. or somewhere inbetween.
I used âThe position has changedâ to detect e.g. if the blind is in the MY position (closed with ventilation) or halfway.
I then soon got a message from Homey that the flow was disabled for being triggered too much, so I put in a notification and saw numerous updates, not just end positions (which I believe the card is intended for).
So then I thought I could put in a condition card to say âand is not movingâ, but that condition isnât working as intended. Though it does prevent Homey from killing the flow from being triggered too much, it still triggered when the shade was not yet in the intended end position. the notification still triggered while the state was not idle and the intended position was not met.
So, concluding, without a lot of trickery it is not possible to have two flows, one for fully open and one for not fully open.
I will have look into that one.
The position changed should only fire if the position value has changed and that should be debounced by Homey as it is a built in capability. Also, the way the app works, it should only update values when it gets an event from Somfy and the shade would have to be moving for that to happens. So it sounds like there is something strange happening if it is making Homey kill the flow because the events will only be checked every 3 seconds max.
Using this flow:
I first used the remote to put it in MY and got this:
then cleared notifications, and remote up gave me:
The erratic order may be due to ansychronous effects
I remember that i once created a flow that when âposition velux has changedâ and my daughter was marked as asleep it marked her awake and opened the velux. It worked fine a long time, but 4-5 times my daughter was sleeping and marked as awake, so everything opened up. I added the position should be bigger then 50% and i never had it again.
I suspect it had to do with the metalblades warming up, and moving a bit, with enough pressure it moves the encoder just enough.
Apart from the erratic order, that all looks normal. The state is a built in capability, windowcoverings_state, that has only three states of Up, Idle and Down. The setting is received from the Somfy via the API and mapped into those. Some covers report just Up and Down and others report Open and Closed, while some will also report âunknownâ when it is neither up or down.
That is basically why I added the âIs Movingâ condition to fill the gap.
I am currently playing with the idea of a global âCommand Completeâ trigger card. When you add the card you can select the device to monitor, then when the app gets the notification from Somfy that a command has finished it fires the trigger card. The card supplies two local tags, one for the success state (true or false) and one is a text field that gives the internal command name that just completed.
But to me it is not really useable. A lot of the positions displayed are not ones I asked for but intermediary ones. I issued only two commands, MY (I think about 0.17) and open. Homey thinks I also placed it in other positions.
These values came with a state ânot movingâ, which isnât so if they are intermediary ones. This is probably because by the times they came though, the movement was already completed. Is Tahoma giving you multiple buffered values when you poll or something like that? Because it is definitely not real time, they come all at once some time after the actual fact.
So moving/not moving isnât corresponding with the situation at the time of the provided position, and state is also useless because it issnât representing the direction of the motor at the time. It says top, but it is idle in the top position. So what does idle mean then?I canât tell the extra positions were arbitrary positions in between. I also canât tell if the last one is the right one if they are handled asynchonously.
And mind you, the number extra positions differs each time. Sometimes I get so many Homey will disable the flow. I also doubt whether the action completed will be of any use if the action is performed with a Somfy remote. Will it say MY if I used that button? And what if I press down and then stop a little while later?
One of the things I try to accomplish is count the number of open screens. I do not want to use polling to do so. I would be much helped with an: âis openedâ and âis (partly) closedâ trigger that only fires when the state actually goes from the one to the other But given what it does now I cannot do that reliably without polling (and that too would get weird results during a âposition stormâ. I would need to use timers too.
I tried a notification with both the local position tag and the actual state from the device. I can somewhat filter bad positions from that too by only using the position if they are the same. But as you can see, during testing my flows got disabled again. That is something I cannot protect myself from.
It would be nice if you could prevent a position storm by giving only the last position per blind if you get many at the same time.
It also gives me 0.95 numbers that should be 1 (1 is also there).
Itâs certainly a tricky problem. The app works by polling for events. When it gets the events there could be, as you have seen, a number of position updates all come in at once. These will all come in sequence and be processed in order but the way Homey reports them could be asynchronous, however the last one in is the one finally stored.
If Homey initiated the command it temporarily boost the polling speed so the updates are spread out more evenly but that canât happen if the command is initiated externally.
I will try to implement some filtering on the events so if the batch contains data for the same target it will just use the last one. That should stop the flood disabling the flow.
I am trying to make the new trigger work with both internal and external actions.
Now I understand the problem from your great description I will see what I can do.
