Yes, and it’s fine. Homey also knows that the position of the blinds has changed, but event doesn’t trigger.
For the test, I made a special flow that checks the blinds’ position and starts 2 minutes after sunset.
So now you have to wait for sunset😁. I you like not to wait so long, you can start it at a dedicated time, let’s say current time plus 1 minute.
This was done already yesterday so I definitely know that Homey gets new data of the position. 
This situation only occurs when the sunset flow is triggered. In all other cases works.
Today I also tested what the rate limits are with running flows on Homey Cloud and found out:
- 15 equal flows in 60 seconds
- 30 different flows in 60 seconds
So it looks that when the sun is going down, no trigger is issued?
You coul make a extra little flow to test it like:
WHEN the sun is going down THEN send me a message.
Interesting:
| — | — |
|---|---|
| Nov 9, 2023 2:32:58 PM | Test1 |
| Nov 9, 2023 2:32:58 PM | Test4 |
Only two triggers were activated.
Or the other variables are already 10, but I presume you took care of that. For contiously testing add 1 every time, if that’s possible.
Might be you are missing interrupts due to high CPU usage?
What happens when you start the 7 Appends card directly after the start button?
Or put some delay between every variable being changed.
2 per 60 sec. This does not make any sense.
I will wait for @Phuturist to say something more about this, as a developer he knows more about the Homey API.
I made the same test in normal flow, HP2023, software 10.0.8 and all scripts run.
I know next to nothing about Homey core and rate limits. I’m not a developer at Athom.
If the trigger card that is not triggering the flow is a custom card I created in the Shelly app I might be able to help you but if it’s a card created by a default capability it’s somewhere hidden in Homey core. But if you have another flows that’s also not working as expected and which is unrelated to the Shelly app or even capabilities in general it sounds like an issue (or feature) of Homey Cloud and you should contact Athom.
FYI, logging on Homey Cloud is pretty much not existing. Athom chooses to only write actual errors to the log on Homey Cloud.
Yes it is. Position changed from Shelly 2.5 
No it’s not. The position changed card is a default card from the windowscovering_set capability. It’s part of Homey core. But as mentioned if, if you have other troubles with flows as well it’s probably not related to these flows but with Homey Cloud in general.
I see, I thought it was a trigger from the Shelly app. I only have this problem right now. Thanks anyway
Hi there, just a quick question:
I just bought homey pro and i was using the cloud feature, but now i can’t connect my homey pro to shelly cloud, i need it for the reason that my shelly cloud is not physically where my homey pro is based, how to overcome this issue?
Cheers
Create a VPN between your Homey and your Shelly devices. Homey Pro is not ment for cloud control and the Shelly app does not support it.
2 Likes
Hi guys, I lost my nerves after 3 weeks of getting shelly H&T plus (gen2) working with homey pro.
none WS, MQTT or BLE is working. on cloud I somethimes have successfull Shelly cloud connection, sometimes on homey, but never together or stable for more than couple of hours.
homey shows me last connected 3 days ago and shelly cloud now get latest info only if I manually activate H&T sensor. I am running both, cable and batteries, similar but also different results. no success on both to have them stable or connected for a longer time
on display I have fully Wi-Fi signal, also BLE and Cloud activated(not sure if that is also connected or not)
direct access, when I activate the signal is working perfectly on my static IP, and also fixed or tuned the WiFi to not cause the issues (disabled roaming, fixed channel associations for 2.4GHz, etc.)
homey has also fixed IP set on my FW, and they should be talk to each other without issues.
I still have “status DEADLINE_EXCEEDED: Timed out” for WS also MQTT…BTE is other story.
the same or similar issues I have with wall display, direct web access withotu any issues. Shelly clould had pending connection over last 2 weeks and homey was working…last day it was online, but now again offline in shelly cloud. Homey shows me the the temp up to date, but in shelly cloud is offline couple of hours. (and yesterady was online - no change on the network or wall display at all).
I got xiaomi for 6Euros yesterday up and running in 30 minutes, or other sensors working without issues after pairing, just shelly is for now loosing my nerves and huge amount of time. do you have any ideas? what I am missing or doing wrong?
Sounds like something in your network / WiFi configuration. Look into stuff like UAPSD, IMGP snooping, DHCP snooping, multicast enhancement, multicast and broadcast control, etc.
ok, understand your point, yes can be a mess sometimes, as I tried several changes last two weeks to tune it. now all is disabled and I also can try to add a secondary AP directly to a public ISP modem and see it there is any improvement and if the connection is more stable.
the question is, if the wifi/network is unstable, then I have no connections to cloud in shelly APP, but I have the successful connections there and no communication in homey in last 3 days. what is the way how they communicate? I also see they can /could speak together with HTTP/WS, and also MQTT and also BLE. (I think it is all local direct communication) and not through shelly cloud to homey cloud.
so if I have sensor in shelly app UP and working, how do I get them to communicate with homey? should just setup ws://:6113/ works? or do I need some special setup? I sometimes saw the /api/shelly, or other URP paths at the end. but not sure if and how it has to be done right. thanks for your response.
just small addition, that within shelly app, both outbound websocket and mqtt shows me disconnected. and to your previous post, all igmp, dhcp, snooping or broadcast settings should be disabled. but will consider to do some test with just ap and modem.
Read the troubleshooting guide from the first post to get hints on connection issues. Gen1 uses CoAP and gen2 uses outbound websocket for communication. Then there is Bluetooth and Zwave devices.
Thanks a lot for your help, yes, it was a network issue.
first I had an ethernet cable connected to another vlan. I wasn’t sure how it works, and didn’t realised that ethernet took over the preference, but the WS/MQTT communication I pointed to a wifi IP. (now corrected)
then I had a second issue, while reconnected to another wifi network for the tests, there I had ports isolation. (also corrected and working)
now I have MQTT connected, and WS also responds to a requests, but I got an error code 404.
Finished; bytes 410, code 404, redir 0/3, auth 0, status -19: Invalid WebSocket handshake response
not sure how this can be fixed, do you have any ideas?
