Added ability to put in JSON in the devid and param.

[steves2j]

Added the option to put in JSON into the devid and param inputs so that the Device Id and Parameters passed on to the particle can be derived from the passed in payload instead of having to replace the options in the node at runtime.

So in the DeviceId input field you could put in "{payload.coreid}" and it would extract the coreid from the payload and use that as the device id.
Same applies for the parameter input field.

[chuank]

Hi @steves2j thanks for the PR!

Including JSON support is a great idea – this allows more advanced users to feed in preformed upstream payloads in JSON. Perhaps this could be extended to allow mustache support?

A key assumption in your PR is that the user knows what key:value pairs are valid for the JSON object. This is not currently easily known until one goes into the source. A simple solution is to add documentation for this.

I suggest, if you are keen, to amend your PR so that a) further sanity checks are made to validate the upstream JSON object before passing it through to the Particle JS API. b) Return errors back to NR to maintain consistency in error-reporting, and finally, c) modify the help files to indicate likewise.

If you're not keen to do this, I'll add the above support for JSON and error checking in my next update, though it might be a while~

[steves2j]

Sure it's something I can look into. However, for me it might be a while as I'm currently trying to track down and issue with your SSE module where it's spawning new event listeners and am getting multiple messages where I should only be getting one. Might be the reconnect or redeploy is not destroying the old listeners.

Anyway. Mustache support could be useful, not quite sure how that would be any more useful than a json object, except I suppose to remove the reliability of having to know the key:value.
Also might be worth having a default capability, just in case the json obj doesn't resolve, instead of raising an error.

[chuank]

Perhaps the keepalive mechanism introduced to fix #16 inadvertently spawned new connections, even though I thought I've done the proper GC'ing on existing connections.

There is also this long-standing issue on particle-iot/particle-api-js#95 that points to the Particle JS API implementation. Those were the things that were left on the to-do plate when I last worked on fixing the multiple connection woes of the SSE node. Previously, before I ported the node to use the Particle JS API (<1.0.0), this was not an issue.

What should the 'default capability' send in lieu of proper JSON? Perhaps whatever has been defined in the node dialog will do, and maybe issuing a warning about an unresolvable JSON (and updating the status label)... or simply block the flow – as a way not to trigger the node unnecessarily.

Mustache is just icing on the cake really, targeting NR users who might already be familiar with it. Providing JSON documentation in help will likely do the trick for advanced users.

[chuank]

Thanks for the PR! Sorry it took a while~