An excellent idea, but unfortunately your GitHub instructions tell people to go to the IDE and create a virtual switch there. That is no longer an option in the new architecture. And the IDE itself will be going away soon.
There are two different options that can be used instead.
First, those who have a smartthings/Aeotec hub can use one of the community-created edge Drivers for virtual devices. You can find those on the quick browse lists in the community – created wiki.
Those who don’t have a hub would have to create a virtual device using the API, which is more complicated. And then I’m not sure your new smartapp is going to work for them. So I’m just going to mention that, but not go into the details at this time.
Also note that once the IDE goes away, there will no longer be an official method for adding custom modes like one for Shabbat. You will still be able to do this through the CLI, but again, that’s more complicated. Of course, if someone already had the mode from before, they should be OK.
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
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.
Hebcal to Google calendar
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.
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.
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.
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.
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>
File "/usr/NAS/Smartthings-Shabbos-Mode/Self_Hosting.py", line 49, in main
File "/usr/lib/python3.10/asyncio/base_events.py", line 646, in run_until_complete
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