Fantastic, just few answers remains :
- diag ID from app (just put there Timeout and your nickname)
- what about controlling it without groups, does it get timeout as well ?
Fantastic, just few answers remains :
That is rather interesting, because nothing of the app has changed but fixing bugs and adding effect selection support.
You are saying that you have the app for years. Could it be that you are still on the old driver in Homey and not on the new cloud driver? (If so pair your grouped device anew in parallel to the original device and see if it works.
Also what kind of timeout do you get. Is it a message? If so please share the exact wording of the error message because there are multiple different timeout errors.
I think I have a similar problem, have the rgb+w 250 string. Was working great until few days ago, the app looks fine, I see the strings in the app yet when I try to control the lights (simply turning off/on) Iām getting timeouts. Im on the homey pro 23
If I make a notification it says: 504: GATEWAY TIMEOUT
Yes, I added something to the FAQ at the top of this thread about the possible errors seen.
Please try power cycling your Twinkly and let me know if it resumes operation with Twinkly.
Thank you a lot @Shakesbeard! Just unplugging the string fixed it!
I tried re-installing the app, changing all the flows, thinking it must be somewhere in the homeyā¦ Yet sometimes the solution is simple
Since recent update Homey can control the on and off functions of my Twinkly againā¦There really isnāt another way to phrase that, context is everything
One of my twinkly lights now shows offline since latest update. Have tried power cycling the device, repair device and deleted and reinstalled twinkly app. Lights still work from twinkly app.
Everything was working prior to the latest twinkly app update.
Okay then. I can only repeat what I have posted in here a thousand billion times already
Literally the previous post and the FAQ at the top of this forum.
Just check point by point to rule out any possible issues on your end.
I have found that changing the dim level causes an error if the dim level is already at the level you want to change and the lights are off. Regardless, if an error is triggered the lights come on - I donāt know if this is the desired action.
Another thing is if the lights are off the dim level is always 0 - So to check dim level I need to first turn on the lights and then check the current dim level.
Test flow:
This sounds like a error. Can you please reproduce this again and send an app diagnostics report right after that.
Be aware that testing mode has issues with timeouts. Please recheck the bahavior with normal flow execution and capute the error message in your timeline instead.
This is by design of the Twinkly device logic.
Setting a dim level will by design turn the device on if it was a 0 dim level before. This is intented design by Homey. I do understand that this has an effect based on how Twinkly reports the dim value.
Personally I think that Twinkly does not really turn off but just dims to 0 when turned off. But that is just a wild guess on my end.
If you need to keep track of the dim level for whatever reason, whilst the device is disabled, add a variable which tracks all non 0 dim values for the device on dim level change.
Test flow:
Outcome:
Diagnostic report: 543b01b4-ba46-4da2-a246-3cf65cd7e22d
It was just an attempt to bypass the error, otherwise I always got a false error notification.
Seem like a Homey Cloud issue. But that is just a wild guess. The submitted diagnostic log is completely empty as if the app is not running at all. Maybe actually try asking Athom support about the cloud system here. Literally Homey Cloud not responding.
Ok, Iāll report this to Athom to check.
Hi @kruza26 , not sure if it solved. I did not spend xmas at home last year so did not have a chance of testing them out
Letās try again, I hope there is at least something in the log now.
Diagnostic report: 368f8ff0-e42c-4190-a159-600111d998b6
Nope. sorry. It delivers absolutely no log output at all, just as if the app was not running
Ok. I will go back to Athoma and report that is still not working.
What about now: f7fd12fb-17cf-4ea2-8b56-0b661d350e5e
Sorry, but still the same emptiness