Email throttled at 5:30AM

[Kebel871]

Sending email thru piston has been throttled lately. Felt like I should report.

It’s the only piston that use send email commands and run only once a day, sending two emails each run.

Here’s the Logs
2017-09-25 05:29:59 +521ms
+1168ms ║Error sending email to [email protected]: Throttled - Too many emails per hour (37)
+1350ms ║Error sending email to [email protected]: Throttled - Too many emails per hour (38)
2017-09-24 05:29:59 +328ms
+1842ms ║Error sending email to [email protected]: Throttled - Too many emails per hour (35)
+2010ms ║Error sending email to [email protected]: Throttled - Too many emails per hour (36)
2017-09-23 05:29:59 +337ms
+1314ms ║Error sending email to [email protected]: Throttled - Too many emails per hour (33)
+1459ms ║Error sending email to [email protected]: Throttled - Too many emails per hour (34)

[ady624]

Lol, same hour every day? I know what the problem is ;))) will fix in the morning

[Kebel871]

Yeah it’s weather forecast + reminders and we usually get up at 5h35

[ady624]

can you retest please?

[Kebel871]

I confirm it worked this morning. Thanks!

[Einars]

I confirm it worked this morning. Thanks

I can confirm. You get up way to early.
All before 06.00 is yesterday

[adavison]

I’m having the same issue for alerts I send for my home alarm, can someone at Webcore help?

[jkp]

How many emails are being sent to you per day from pistons and including this forum? There is a daily rate limit of 50 emails.

Notice - Forum and webCoRE emails are down

NOTICE Please note that our email provider (mailgun) is currently down due to excessive use which has pushed us over the rate limits (max 10k emails per day). We have killed all the backed up emails, so hopefully emails will fire up again soon. The biggest culprit appears to be the forum… with over 1.3 million emails sent so far! In preparation for when emails start working again, and to prevent a re-occurrence, we have been forced to disable the daily digest emails and have limited each use…

[adavison]

So today, loads as been testing new Webcore pistons re moving from old app to new and can’t use STM anymore, so had to add loads of virtual switches etc to drive the the alarm and the STHM… But each time my alarm changes status it send for emails (2 emails, 2 emails that convey to SMS) so if I left the home 12 times i;d hit the limit, anyway of increasing it to 100?

[adavison]

Happy to donate some cash for my account to have 100 emails per day???

[jkp]

Doubtful but not my call. You need someone higher to make that decision.

[adavison]

Do you know if STHM will be able to be integrated into webcore in the future? or are Samsung going to keep it locked down?

[jkp]

Don’t know at this time. Depends on ST releasing their final API and see what happens with webCoRE.

You can manage STHM indirectly with webCoRE and virtual devices or a combination of webCoRE and automations.

[ipaterson]

Happy to donate some cash for my account to have 100 emails per day???

You can use a third party service to send emails as long as it provides an API. For example, with Integromat you can set up a webhook to trigger an automation, then your webCoRE piston can be updated to “Make a web request” instead of “Send email” to hit your emailer. You can integrate with much more than email and there is a free tier that may work for you.

I have a simple Integromat scenario that sends “urgent messages.” It sends email through my personal Gmail account (i.e. no per-email fees) to my SMS email address. I set up my phone contacts with a special text tone for texts coming from that email address and enabled Emergency Bypass so I get any urgent messages regardless of whether the phone is in Do Not Disturb or silent mode.

My notification sender piston supports a “target” argument to specify to which channel the message should be delivered.

If you go that route I recommend making a reusable piston to send email (read up on execute piston and $args to call it) so that you can swap out the emailer if necessary without editing all your pistons that send email. Web requests and execute piston calls do not incur fees, so your fee schedule would be controlled by whichever third party service you use to send the emails.