in smartthings the condition of the child device is reflected very quickly but the state of the parents is very long and sometimes I refresh manually.
if I go to smartthings and go to ActionTilesV6 and just press save. ActionTiles will put the switches in good condition?
It should force sync to the current values shown in Current States in the IDE. Give it a try?
I push top button on wink relay. After, I push SAVE on ActionTilesV6 and my switch synchronized.
It looks like the child devices not updating their state properly is a known platform issue affecting multiple device handlers:
Once the platform issues are resolved, I would expect the event issues with Wink Relay child switches to be resolved.
what I do not understand is that the CHILD devices and my Fibaro Controller for my LED works fine with Sharptools and HomeRemote but not with ActionTiles ( official service integrated)
The main UI of SharpTools queries the state of the device when the app is first loaded and can refresh the state every X seconds. ActionTiles uses event subscriptions and push events to update the dashboard.
The manual refreshing seems to work, but the subscriptions/events are not working. This is why the SmartThings mobile app will seem out of sync with the actual status but when you change pages and come back it will refresh with the correct state. Normally the SmartThings mobile app is also relying on these push events to stay up to date.
This is also why the main UI of SharpTools stays up to date as it manually refreshes, but subscriptions against the child switches for Tasker or widgets would not stay in sync as they rely on the subscriptions/events.
Just an update that the issues with the ‘switch’ attributes not staying in sync are expected to be fixed in the next SmartThings platform deployment.
The problem is with the
isComponent=true on the call to
addChildDevice around line 128. If you set it to
false and delete and re-add your Wink Relay it should work, but this also shows the child switches individually in the main list and with a number of quirks since the DTH wasn’t designed with this in mind. The issue with Child devices and
isComponent=true is expected to be fixed in the next platform deployment, but if it’s absolutely critical to you and you don’t mind the quirks, feel free to make the change to the code and re-add your devices.
thanks you. it works very well. the individual switch in smartthings is very convenient. It remains to be seen that they are going to be quirks.
And in ActionTiles he reflected instantly
Thanks again Joshua and all the others for working on this! I wish I could contribute more but I am not a programmer. Please let me know if you want any logs or testing done on my side. I have 3 Wink Relays and an extensive Smartthings setup. Also have Actiontiles running on them. I have yet to put the push buttons into production on my system, outside of just the manual button presses.
It’s really just waiting on SmartThings for the platform fix at this point. If I remember correctly, they usually push out updates on a weekly basis. It used to be every Tuesday, but I haven’t been paying attention to their timing lately.
SmartThings has pushed out the platform update which resolves the issue with child device state not triggering immediately. Please give it a try and let me know if the child events / states are now showing up in the SmartThings mobile app and third party apps like ActionTiles.
everything works perfectly, thank you
Just bought a Relay due to this integration in particular. Thank you very much for your diligence Joshua, this makes this device incredibly useful as most of my switches are WeMo (incompatible with Wink) and I tend to only control my devices with ST routines sent via Alexa commands. Just really liked the sensor and intercom capabilities of the relay, will probably just use SmartTiles on the display. Thanks again man, I’ll be sure to let you know how it works out for me when I move into my new place next month and if I can contribute I’ll definitely put in a PR on GitHub
It’s working great now
What a great app. Thanks for all your work Joshua! It’s great to finally be able to disable the annoying stock Wink app.
Everything is working excellent except for one bug that I’m having. The bottom button appears to be reporting as the top button. If I press either button “Button pushed: Top” appears on the Wink screen. And in the device handler the topButton attribute changes when I press either button.
I don’t think it’s a hardware problem, because the stock Wink app detects which button I pressed correctly when it is running.
Thanks for the report on the buttons. I’ll take a look.
I have a similar issue, but I think I might be having a hardware problem… When I use the top button it works as expected (press once the light toggles on, press again it toggles off). But, if the top light/relay is off and I press the bottom button, the top relay turns on while the button is depressed, then turns back off when the button is released, and the display shows the “Button pushed: Top”.
The bottom relay is not attached to anything, the top relay is attached to a light.
Since the STWinkRelay app doesn’t have any linkage between the button presses and the lights at this moment, it’s likely either a hardware issue or Wink software issue. For the time being, you can ignore the “Button pushed” messages as I don’t think the logic for displaying which button is pushed is correct.
That being said, I would try restarting your Wink Relay by pressing the button under the edge of the body (below screen). Before I developed the STWinkRelay app, I found that if I ran too many side-loaded apps, the base Wink app (and the device itself) would start operating funky and a reset of the Wink Relay often helped.