Custom nodes look great, but I need them on the Edge ;-)

Hi

Ok, I am a broken record :wink:

Having started using Edge Workflows aggressively as I have said in the past, the inability to call other workflows makes me hesitate to move forward too much.

Implementing complex logic, that needs to be used in multiple parts (or nodes with lots of configuration) is problematic and error prone, as a small change requires editing potentially other nodes.

The breaks DRY.

So for me calling other workflows (and ideally having the custom nodes) available in Edge Workflows are probably the main barrier preventing me from going all in on Edge Workflows.

We definitely expected people to want the custom nodes on edge, and our intent is to offer it fairly soon. We released them cloud-only so we can refine the functionality - it’s a lot easier to fix things on the cloud than to make people update the Edge Agent if we want to change behavior or find bugs.

As for workflow-to-workflow triggers, an easy workaround for now would be to use the Edge Agent’s local webserver. One workflow can use an HTTP node to invoke localhost, which can then be used to trigger another workflow using the HTTP Request Trigger.

We’ll have to think about a good way to support workflow-to-workflow triggers properly on edge. The first step is to bring the Virtual Button to edge, which is something in the works.

Hi Brandon.

Yep HTTP request is where I am going to go for now, though would love to see REDIS subscribe, big advantage is REDIS PIBUSB is a queue, where as HTTP can come it all over the place :wink:

Main thing is now we have to make sure a response is correctly formed in the HTTP response, and I am actually need the other flow to be adding to the payload. So Custom nodes is more in line for me :wink:

Thanks for all the hard work.

T

Redis Triggers is something we do want to add.

In terms of the HTTP Trigger, you can scope it to only allowing traffic internal to the gateway by setting the webserver.address agent configuration value to localhost or 127.0.0.1. This will prevent anyone else on the network from being able to access that interface. Of course, if you are using the webserver for communication over the local network, you wouldn’t want to change that address.

Any progress in bringing custom nodes to edge workflows?