EEVblog Electronics Community Forum
General => General Technical Chat => Topic started by: Jester on August 16, 2023, 08:16:50 am
-
Really really simple, door opens reliable notification to iphone (home or away)
After countless google searches it seems there are countless not so reliable hyped solutions.
I prefer to avoid cloud based solutions and apps that break (think insteon), just seems like a mistake waiting to happen. I don't want to pay ongoing monthly fees. $3 month today will likely be $200 year tomorrow with inflation.
I do have Wifi close to sensor. The sensor can be powered if need be.
Contact may not be activated for weeks at a time and from what I have read zigbee solutions have a tendency to drop nodes when not active for extended periods.
I did use an Arduino/ESP8266 to send gmail for a while however I had to constantly tell gmail to allow unsecured email and then they would simply revert back to the secured mode so it's basically unreliable.
Tried another Arduino mail sender (not gmail based) sketch yesterday and was able to get it to the point where it connected via local wifi to my email provider SMTP port, but then timed out waiting for a ELO? response so ultimately was unable to actually send the email. I'm not knowledgeable about the various hand shakes that need to take place between the Arduino and the email provider to actually send an email perhaps I'm closer than I think with this approach?
Tried IFTTT , triggered it and it reported email sent but I never actually received the email and this method appears to be hit and miss at the best of times from what I can deduce.
Surely there must be a simple/reliable/no monthly fee solution?
Please share your solutions, I can't be the only one on the planet.
-
I use a Home Easy magnetic door contact, powered by a coin cell. Transmits a proprietary OOK one way message at 433.92 MHz, received and decoded by an RFXCOM transceiver. This is connected to a UniPi Neuron controller running Node-RED. I use Prowl to send notifications to my iPhone. The only software I had to ‘develop’ is a flow comprising just three nodes.
The only cloud bit is Prowl’s server, but something like that is pretty much unavoidable.
No fees or subscriptions involved.
-
I think your main problem is in the getting from a local device to an email part. Maybe there are other email providers which don't reject automated logins for email sending the way gmail does, I once had this problem when designing a prototype device involving a raspberry pi. I'd think the arduino and esp parts is probably quite reliable, I'd stick with that and work on getting a more reliable way to send the emails. Part of me wonders about a Rasp Pi with a browser open and a python script interacting with the browser to access an email webpage as if it were a human doing it, but that would fail whenever anything about the page layout changed or if a CAPTCHA ever appeared. A Pi should definitely be an easier setup for sending emails from than an Arduino, being a full Linux OS with all the system tools rather than just a microcontrolelr running one piece of code.
-
I think your main problem is in the getting from a local device to an email part. Maybe there are other email providers which don't reject automated logins for email sending the way gmail does, I once had this problem when designing a prototype device involving a raspberry pi. I'd think the arduino and esp parts is probably quite reliable, I'd stick with that and work on getting a more reliable way to send the emails. Part of me wonders about a Rasp Pi with a browser open and a python script interacting with the browser to access an email webpage as if it were a human doing it, but that would fail whenever anything about the page layout changed or if a CAPTCHA ever appeared. A Pi should definitely be an easier setup for sending emails from than an Arduino, being a full Linux OS with all the system tools rather than just a microcontrolelr running one piece of code.
Agreed, I was able to get this working using IFTTT, this is easier because all you have to do is get the ESP8266 to access the web address associated with your webhook and IFTTT then takes care of the email. I don't have a sense if the IFFT server will prove reliable over time, some comments indicate that the server seems to loose your webhook from time to time and you need to regenerate the webhook. Only time will tell?
Back to the direct email approach, now that I'm with a non gmail service that actually has tech support I'm inclined to take another stab at that approach, I did make it as far as connecting with my hosts mail server, but did not get past the ELLO phase. Does anyone have a link to the various handshakes required to send and email?
-
If you want email to work properly in today's email world you should:
- make sure to/from addresses are real (at least legitimate looking e.g. noreply@properdomain.com
- add SPF entries for your IP/host that the email comes from
- ensure your IP is not blacklisted in DNSBL etc
That will be the reason Gmail somewhat legitimately marks your emails as bad.
Its not that hard to get right. I use Gmail and have no issues with emails sent like this. I do run a local postfix email server in a Docker to forward them on though.
-
Another option would be something like Pushbullet. There are Arduino libraries for that. Basically it sends a notification to a Pushbullet server and Pushbullet handles it from there sending you an app notification. Free for quite a few pushes per month.
Have we not already done this?
https://www.eevblog.com/forum/projects/arduino-send-sms-via-local-wifi-in-canada/ (https://www.eevblog.com/forum/projects/arduino-send-sms-via-local-wifi-in-canada/)
-
Another option would be something like Pushbullet. There are Arduino libraries for that. Basically it sends a notification to a Pushbullet server and Pushbullet handles it from there sending you an app notification. Free for quite a few pushes per month.
Have we not already done this?
https://www.eevblog.com/forum/projects/arduino-send-sms-via-local-wifi-in-canada/ (https://www.eevblog.com/forum/projects/arduino-send-sms-via-local-wifi-in-canada/)
I have the SMS aspect working indirectly now. My cell provider has a service that if you send an email to a particular email address with your mobile # appended, the service sends an SMS message. That's working. This seems completely reliable. However I'm relying on IFTTT to generate the email, and I'm not sure IFTTT is reliable?
I would be more comfortable generating the email and sending it to my mail provider. Need to figure out the required handshake, presently getiing stuck at the ELLO handshake stage after connecting with the mail server.
Still need to look into pushbullet.
-
Well it's not ELLO if that's what you're using - you've written that a few times. Don't reinvent the wheel. Use an existing library like:
https://www.arduino.cc/reference/en/libraries/emailsender/ (https://www.arduino.cc/reference/en/libraries/emailsender/)
-
Well it's not ELLO if that's what you're using - you've written that a few times. Don't reinvent the wheel. Use an existing library like:
https://www.arduino.cc/reference/en/libraries/emailsender/ (https://www.arduino.cc/reference/en/libraries/emailsender/)
I think some reinvention of the wheel may be required as of 2022, because (AFAIK), GMail now refuses to send unsecured emails, and I don't think the various iterations of these Arduino email senders actually use secure SSL (I could be wrong but that's my understanding). A year or so back I was sending GMail with one of these programs, however to do so required going into the GMail settings and disabling secure emails. The problem at the time was a short time later GMail would automatically switch the settings back to secure. Now that setting has been removed from the settings altogether.
Using the latest version (3.0.11) in your link, the program gets hung up after getting the SMTP status code 235 (Authentication successful response), and then returns an error SMTP AUTH error (535-5.7.8 Username and Password not accepted. This error is commonly associated with not having the server setup for less secure apps.
I think this SMTP flow diagram shows how things were at some point, but I believe it's probably out of date as of 2023, I don't even see code 235. Or the mail server I'm connecting to uses an older protocol (perhaps 235 responses instead of 250)?
[attachimg=1]
Any SMTP experts out there?