I’m also having the same problem with selecting pm on iOS. Tried on both my iPad and iPhone. Not a problem on my android tablet so it must be an iOS issue.
Have just tried on a different iPhone running an older iOS, time format is in 24h which works fine?? strange?
I haven’t heard of this one yet… if you haven’t already, please shoot a note over to support
Posted in correct thread.
Post questions here…
Thanks for the responses, i believe that this is a Smartthings App issue as it have the same issue when i use SmartApps.
Just started using CoRE and love it! After Rule Machine I used IFTTT for awhile, but too limited. Just wanted to say thanks so much for this great tool.
Don’t know if this has been identified before, but I’ve discovered that if you change the Piston Mode (say from Or-If to Latching) after setting conditions & actions for a secondary state in the originally selected Piston Mode (here, I was originally using an Or-If Piston, so it was the “Or-If” conditions and actions for the “Or-If” state), then –
the secondary state conditions entered in the original Piston Mode remain, but
the secondary state actions entered in the original Piston Mode disappear.
As a result, I re-entered the secondary state actions for the new Piston Mode (here, the “But if” state for a Latching Piston). While I was doing this, I ended up deciding on using slightly different actions (specifically, the new actions did not control my Sonos speakers).
Today (a few weeks later), I noticed that one of my Sonos speakers still listed the Piston in that device’s SmartApps tab. I clicked on the Piston and didn’t see the device listed in any of the conditions or actions. I clicked “rebuild” Piston and saved it, but the Sonos device still showed the piston in the SmartApps tab. Then I remembered that I had changed the Piston Mode, and changed the Piston back to an Or-If Piston. Sure enough, the actions that I had originally entered for the “Or-If” state were still there!
So I deleted those actions and then saved the Piston. The IDE logs showed that the subscriptions were updated and the Piston no longer appeared in the Sonos device’s SmartApp tab.
Is there a way to clear out the secondary state actions / force an update of the subscriptions to the new secondary state conditions when changing the Piston Mode? If not, you should probably not allow a change in the Piston Mode until all secondary conditions are deleted…
Where can I find instructions on how to actually install this?
I think I’ve stumbled upon a bug, maybe after a recent update but I cannot be 100% sure, (since githib integration came to the UK I update more frequently). I have this piston:
(copied from a great example that you gave to me)
It was working just perfectly. Recently it comes on just fine, but then the countdown keeps resetting every time my hue lights refresh their state. The counter gets to 4.40 (sometimes more, sometimes less), then jumps back to 5.00. All the time the Piston does not change state, the only thing that happens is the hue lights refresh.
I use the custom DTH from @infofiend, but I’ve not made any changes there. ([UPDATED 4/19/17] Hue B Smart (Smart and FAST Hue Lighting))
Any help would be much appreciated as this is really messing with everything! I tried recreating the Piston from scratch, I’ve restarted the hub, I don’t know what else to try…
In the ‘THEN’ enable ‘Only execute on condition state change’. This is what I do and it stops the counter resetting.
As an aside. You stated that we have Github integration in the UK. When did that happen?
Thanks so much @bobbles Where do you mean? I the TCP options or somewhere else?
Do you mean on ‘Piston state change’?
I enabled it month or so ago, I’ll find the link…
Yes. The very top option in your screenshot. Slide the button across.
Are you in UK on a V1 or V2 hub?
Thanks, will try it now. Am in the UK, v2.
Here is the link I used to kick Github off again:
I raised the lack of github integration with ST support 6 months ago.
They replied that is was never going to be provided on the UK server.
Oh well. I will give it a try.
Thanks for the info.
You’re welcome. Thank YOU for the info in fact. This totally solved my problem, and I leave my TCP in place to allow it to flip/flop. I wonder why this suddenly became a problem though…
It’s strange the contradictory answers people have received re: UK Github integrated. There is no clean way to get in to activate it, apart from that I just supplied. Odd. Also the OP mentioned that it was ST support who had provided it!
Many thanks once again, you rescued me from a (finally) almost accepting family.
Possible bug found.
I have installed the latest version - v0.3.163.20161102 (which in the smartapp reports as v0.3.162.20161028) but the bug I have found is based on not being able to choose PM for a Custom time on a simple piston:
-condition 1 - nest thermostat heating set point less than or equal to 22°C
- condition 2 - and time between 5:30pm and 10:30pm
The problem is, when you choose pm on the iOS time slider, it always saves as am. Regardless of what device invokes the piston and time type:
Try to change to am and back to pm? Unfortunately, that is an UI problem, not sure how CoRE can create/fix it