Trying to send messages from IFTTT to node-RED using Telegram. (Or is there a better medium to communicate IFTTT > node-RED???)
IFTTT Telegram action service is programmed to send what it calls a 'Private chat' (sorry - first time I've used Telegram!).
I can now receive the message on my phone from IFTTT, but unsure how to get the private chat into node-RED via node-red-contrib-telegrambot
I have however successfully setup a 'node-red-bot', which I can use to send messages between node-RED and my phone as per the node's readme. But that doesn't help me get messages from IFTTTT.
You can go direct to NR from IFTTT if you allow access to a URL from the Internet.
One of the limitations of Telegram bots - which makes sense - is that bots cannot communicate with each other. So if you have a bot that IFTTT is feeding, it cannot then interact with your Node-RED based bot I'm afraid.
If you want to avoid opening a Node-RED instance to the Internet, what you need is a listener that can be contacted direct from IFTTT and will then be polled by Node-RED. Actually, you could run both on a single device if you had to and in fact, with a little help from LUA, you could persuade NGINX to do the magic. Meaning that your more complex and therefore potentially more vulnerable Node-RED instance was kept away from the Internet.
Of course, you could also set up a very simple node.js service as well with just a single job and protected behind NGINX or some other web-server/revers-proxy. A free tier on Azure would probably do the job.
I'm surprised that IFTTT doesn't have a MQTT service...
...and equally surprised that there isn't a push (receiver) node for node-RED!
but that's probably my simplistic view of how tech works.
I really don't want to over-complicate this by adding additional servers, for a 'want' rather than a 'need'. So I'll leave telegram for now, and rethink how to do this.
BTW, my end goal is to send 'Ring Doorbell' alerts to my 'Google Home' devices, so that the doorbell is heard throughout our home. There is a node-red-contrib-ring-doorbell node, however it suffers from latency, is buggy, and the author doesn't respond to issues.
I think that's because you need an Internet connected MQTT server and tools like IFTTT mainly revolves around paid services (someone has to pay for it of course).
Connecting Node-RED to the IFTTT Maker node is trivial and works fine. There are also plenty of IFTTT nodes:
I have a cheap wireless doorbell you can buy from most DIY stores or Amazon and that works just fine with Node-RED. A door bell press rings the wireless ringer direct but also triggers a flow in Node-RED that is recorded and forwarded on to Telegram where it reaches me anywhere in the world within a few seconds. Of course, I can also trigger the ringer from Node-RED so I could simply get more of them and put them anywhere. I have two one on the ground floor and one on the landing not that I really need the second but it is occasionally useful to reach the attic.
I could also link this to my Google Home device I guess but I don't see the need. The complexity is more than any benefit.
First world problems of buying overly complex door bells that the US police love because they are given almost unrestricted access to the video (as doubtless the bad guys get as well) and connecting to a Google device with uncertain privacy does seem like a bit of a stretch too far for me - but then I am paranoid so I guess that makes sense.
Aah but... I could either buy some Ring chime's @ Ā£29 each which announces visitors, or link to my Google home devices which would do the same job. Considering that I've Google home devices up & downstairs already, and also being a tight Yorkshireman....
Doesn't that just act as a 'output' node?? ie there is no 'input' node (yet)?
Fair enough. Though it is hard enough to persuade Mrs K. to allow a doorbell that does more than do "ding dong"
Personally, I'm still not convinced that connecting much to the Google data black hole is a good idea. We have a Home in the kitchen which is nice enough but I've been trying to get out of the Google infrastructure as much as possible. I want HA stuff that works without the Internet. I only allow anything that still works if the Internet is cut off or that I can do without. I've seen too many people bitten by services being turned off - that includes Nest & Google of course, that's in addition to concerns over privacy. I think the privacy issues are likely to get a LOT worse over the next few years the way political issues are facing up right now.
Sorry, I'll get off my hobby horse now.
Well, there are a couple and node-red-contrib-ifttt-broker seems to support input and output? Bearing in mind that I've not tried any of them recently.
Indeed, I only use IFTTT to get copies of Twitter posts/reposts/likes and save them to Google Docs and to repost saved Feedly articles to Twitter. My Google drive is backed up to my NAS in case you were wondering.
Truth is that it is easy with Node-RED to set up an http-in node to act as a web-hook. You use the maker extension in IFTTT to connect tot he webhook. It looks more complex than it really is. Though as I said, I'd personally set up a more specific web endpoint so that I didn't need to connect my HA Node-RED instance to the web. There are loads of simple tutorials for setting up simple ExpressJS listeners, stick that behind NGINX or another lightweight web server doing the HTTPS termination and you are good to go. Stricktly speaking, you don't need the web server of course and it isn't that hard to set a Node.js ExpressJS app to use HTTPS as you know. But web servers tend to have better default security settings and may be easier to set up with secure headers and such like.
As I've been looking at uibuilder security recently, it has made me realise that Node-RED really doesn't handle some security best practices out of the box. Something that I will try to address when I have the time. That makes me even more reluctant to connect a NR instance direct to the Internet.
A webhook is just an API endpoint - a web page if you like that responds with data rather than something human readable. They are incredibly powerful which is why so many web services support them. They are also really easy to use since they only require a very simple web response.