Input node?

[jmikerq]

Hi,

I see that you had mentioned about an input node that is coming soon. Do you have an approximate timeline for that input node?

Thanks, Michael Qiu

[lorenwest]

I've been using the HTTP node as input for IFTTT, and when considering input functionality for this node, it's essentially copying the HTTP node.

Could you describe the value you'd like to see from adding input functionality to this vs. suggesting the HTTP node? I'd like to understand this value to help craft the feature.

Thanks, -Loren

[entspannt]

Hi Loren, To be honest I haven't found out how to correctly set the HTTP node up. For me this approach would be enough.

Can you tell me how I can do that/where I can find information of how to link node red with IFTTT via HTTP?

Thanks, Steffen

[lorenwest]

Google "node red ifttt input". My search result shows a pretty detailed explanation on the 2nd hit.

[jmikerq]

@lorenwest , I had a test with the input function with ifttt, and I think you are right! It doesn't seem like there is a need for another HTTP request node.

[lorenwest]

Based on the frequency of this request, maybe the role we could play is documenting how it's done using the HTTP node.

Or, continue with the advise of googling "node red ifttt input" :)

[Shogun1978]

I would like to use a IFTTT input node. Yes, I googled "node red ifttt input" ;-) But think this is pretty complicated and in my case (I have a local installation of node-red, not in a cloud environment), it looks like I need to do a port forwarding to reach my installation - obviously not a good idea. So I really would prefer an input node.

[lorenwest]

Unfortunately adding IFTTT input to this library won't get around the complexities of inbound HTTP including port forwarding, tunneling, https security, certificate management, etc.

It would, however, provide a place to document all the things you have to do to get inbound IFTTT running, so in that regard I'd be happy to accept a pull request with this feature.

[Shogun1978]

I see the problem. As an easier alternative (also with routing/network forward) it would great to have an MQTT client in IFTTT. Here it's possible to use encryption, username/password out of the box. Unfortunately there is no such service. Via MQTT it would be much easier to get data into various systems (IOBroker, node-red etc.). But this is far beyond my programming skills.

[lorenwest]

I'm not so sure I want to expose my MQTT traffic directly to IFTTT. It might make it easier to integrate inbound IFTTT, but letting a 3rd party see all my MQTT traffic wouldn't pass my internal security/privacy audits.

[Shogun1978]

True... But with port forwarding (on non-standard external port), username/password and encryption it could be ok. But for sure: an inbound IFTTT would be the better choice (if possible).

[lorenwest]

If we did this, we'd for sure require login and secure the traffic between our MQTT servers and IFTTT, but the point about extending my MQTT bus directly to a 3rd party (ifttt.com) and having them see all my MQTT traffic and being able to issue messages onto my MQTT bus is the breaking point. It's not worth it just to make inbound IFTTT traffic easier.

There's a reason inbound traffic is hard, and requires a different level of tech. understanding to get working. The attack vector for inbound traffic is an order of magnitude more complex than for outbound traffic.