For the moment, yes. But that’s only during this transition phase, and you are trying to provide an after groovy solution, so you need something more long-term.
Importantly, changing the mode is technically not necessary in my implementation. I’ll have to update the exact instructions for the final version of smartthings. But I want to get a working version as soon as possible.
Understood, and I think that it’s great that you’ve done this. Not only will it help people looking to solve this specific use case, I think it’s also a very good example of how groovy smart apps might be migrated to the new architecture.
Here’s the announcement about the IDE being shut down. That could happen at any time now.
[quote=“SmartThings, post:1, topic:246280”]
Q1 of 2023
.
· Complete 1st Party DTH migrations
.
· Shutdown Graph IDE
[/quote]
Don’t forget that the API browser from @TAustin allows you to create virtual devices and location modes via the browser vs having to use the CLI or the APIs.
I tried using that app a few years ago and never got it working reliably. For years, I now use IFTTT. What I do (in short) is use Hebcal to add a new calendar to my Google account with customized local candle Lighting and havdallah times. Then I use an IFTTT routine to turn on and off a virtual switch when it sees those events start. From there, I trigger the automations, etc.
Step 1
Hebcal to Google calendar
Step 2
Ifttt routine controlling a smartthings device
The only thing to note is that IFTTT no longer guarantees immediate responses for these type of routines, unless you pay for their service.
Step 3. Optional, if you want precise control.
As a workaround, I use this method to find the candle Lighting and havdallah times much earlier than I want them to be controlled. Then, I use the new edge drivers “Virtual Calendar”, to get accurate automations to the minute. For instance, ifttt would trigger a virtual device called “IFTTT Shabbas apx start/end”. Then l would have a routine which triggers a sabbath mode Prep 44 minutes before candle Lighting, another routine at candle Lighting, and a third at the 18 minutes. Then another routine at havdallah.
(misspelling for the speaker notification was intentional, to try to get the most accurate pronunciation.
Have you checked it lately? A number of people have reported that the Ifttt/SmartThings integration is currently broken. IFTTT is working on a new version to work with the new architecture and they rolled it out for a couple of days, but then withdrew it again because they needed to do more work on it.
It worked this weekend. I just tested one of my other ifttt routines and they work as well. I did rebuild my ifttt routines last Tuesday or so. Maybe those newer ones work?
I recall also having some trouble. I had to add devices via linked services in the smartthings app, and not by creating a new connection in ifttt.
I agree that it may not work well for new ifttt accounts. Hopefully it won’t break.
They definitely seem to be working on it, so I expect this just to be a transition glitch and to get straightened out pretty soon. Hopefully.
BTW, it appears my current ifttt routines still work, but I can’t edit them. The device menu shows empty. Hopefully they migrate soon to the new system.
Nice solution. The best solution is the one that works! I actually tried to replace shabbat-and-holiday-modes with a google calendar/ifttt integration, but I couldn’t quite figure out how to get it to work. That was actually one of the reasons that I coded a replacement. I personally am not a huge fan of IFTTT due to their limitations on their free tier and long latencies. My code actually does not rely on hebcal, and instead calculates all the calendar information locally. The only two points of failure are AWS and smartthings. If we ever become able to run apps directly on the hub, then a local version of this would be the ultimate solution.
Thank you so much for your work on this SmartApp replacement for Shabbat-and-Holiday-Modes. I am attempting to follow your AWS instructions as I too don’t have a linux server available. I am stuck on the instruction:
“In Amazon EventBridge, create a trigger called ‘Run_Shabbos_Mode’ (it must be called exactly that), and schedule it with any valid cron() expression. Set it to run the lambda function ‘Shabbos_Mode_Activator’.”
I just was unsure about when it should be scheduled to run via cron. Can you offer a more specific schedule like you did in your next instruction:
“run the function ‘Get_Sunset_Time’ before the earliest sunset of the year in your location every day.”
Thank you again for posting your work on this as it will truly be helpful!
‘Run_Shabbos_Mode’ can be set to literally any valid cron expression, because it’s overwritten everyday anyways by the ‘Get_Sunset_Time’ lambda function. The program works in two steps; at the same time everyday ‘Get_Sunset_Time’ runs, and as implied, calculates the time of sunset in your area. It then schedules ‘Run_Shabbos_Mode’ to run at sunset (through amazon eventbridge), which calculates if the next day is shabbos or yom tov and chooses what to do accordingly.
Therefore, ‘Get_Sunset_Time’ must be set to run before sunset everyday (it could honestly be set to run at 8 in the morning, but I felt that an hour before sunset was a good time), and it will automatically schedule ‘Run_Shabbos_Mode’ to run at sunset. The reason why you need to set a trigger at all for ‘Run_Shabbos_Mode’ is because even though I could create an eventbridge schedule through amazon’s API, I couldn’t figure out how to set ‘Run_Shabbos_Mode’ as the target.
Thank you for your work.
Interesting, did you use someone else’s calculations? Does this account for those located in Israel and the diaspora?
It would be nice if we could customize the end of shabbat times.
I used the excellent python zmanim library, to do completely local calculations for both the sunset time as well as the jewish date. The library natively supports Israel, so I’ve updated it to support that just now. More importantly, in doing so I discovered a critical bug that would cause it to fail whenever shabbos falls out on rosh chodesh (!). I’ve since fixed that, but anyone who has already downloaded the old version should replace it immediately with the updated version!!
As for changing the end time of shabbos, the library only has a built in mode for 72 minutes. With a little bit more work, it should be possible to put in a custom time, so perhaps I’ll do that in the future.
@Rafael_M I tried to install this today. After I installed it I wanted to test it so I ran python3 Self_Hosting.py and expected it to switch the Shabbos Mode Switch off but it didn’t. Not sure exactly it is designed to work. I created the virtual device with an edge driver since rather than the IDE, not sure if that has anything to do with it.
The self_hosting.py file only triggers the switch under 2 conditions: When today is a weekday and tomorrow is shabbos (or yom tov), and vice versa. Even then it waits until sunset first. If you’d like to test at least its ability to change the switch from on to off, then you can add main('off')
or main('on')
(depending on whether you want the switch off or on) to the bottom of the code, and then run it. Note that this test will only work where none of the two conditions delineated above apply.
Just tried your suggestion and it threw an error and didn’t change the switch status. Here is the traceback.
/usr/NAS/Smartthings-Shabbos-Mode/Self_Hosting.py:48: DeprecationWarning: There is no current event loop
loop = asyncio.get_event_loop()
Traceback (most recent call last):
File "/usr/NAS/Smartthings-Shabbos-Mode/Self_Hosting.py", line 74, in <module>
main('off')
File "/usr/NAS/Smartthings-Shabbos-Mode/Self_Hosting.py", line 49, in main
loop.run_until_complete(update_shabbos_switch(mode))
File "/usr/lib/python3.10/asyncio/base_events.py", line 646, in run_until_complete
return future.result()
File "/usr/NAS/Smartthings-Shabbos-Mode/Self_Hosting.py", line 38, in update_shabbos_switch
while devices[i].name.lower() != 'shabbos mode switch':
IndexError: list index out of range
@Ephrayim that error indicates that your simulated switch is not being detected by the program. Is it possible that it is not named ‘Shabbos Mode Switch’ (apostrophes excluded)? You can paste & run this code at the bottom of the program to spit out a list of all devices that can be detected:
async def test():
async with aiohttp.ClientSession() as session:
api = pysmartthings.SmartThings(session, token)
devices = await api.devices()
for i in range(len(devices)):
print(devices[i].name)
loop = asyncio.get_event_loop()
loop.run_until_complete(test())
loop.close()
Thanks got it working! Looks like your program is using the device name rather than label. You are unable to modify the device name from the Smartthings app so perhaps you might consider using that instead especially since the ability to create virtual devices through the IDE will soon no longer be possible. Moreover, the virtual switch using the edge drivers runs locally unlike the simulated switch which runs in the cloud and creating the virtual switch in app you are unable to modify the device name.