Benefits or Drawbacks of NodeRED integration?

[Andrew Jawitz]

Hello All,

 Before I discovered Home Assistant somewhat recently, the only other platform that offered similar accessibility and broad cross-platform support was/is NodeRED.  Of course NR isnt really a home control/automation platform per se, but rather an "Interface for Wiring the Internet of Things".  Obviously, the two platforms are structured in completely different ways as NR is based on Node.js and HA on Python.  It is precisely for this reason however, that the two relative strengths and weaknesses of the two platforms might complement each other more than they would replicate the same functions.  

  The Python-based configuration of Home Assistant for example, makes it a really solid and stable host for things that require persistence like presence detection.  The main drawback to this approach is in the front-end.  The fact that all user-configurations must be applied directly to the .yaml script on the host machine, makes the front-end more of a REactive interface than an active dashboard.  

  NodeRED basically functions entirely as a front-end through which various connections can be made visually.  This visual approach makes it especially popular as a tool for setting up IOT protocols like MQTT.

  Perhaps then an ideal setup would be to use NodeRED as the visual front end for the configuration.yaml script?  NodeRED can write directly to python scripts via its default exec node as explained here- http://stackoverflow.com/questions/32057882/how-to-trigger-python-script-on-raspberry-pi-from-node-red.  Users could then edit the .yaml file either through a custom NodeRED flow or a preconfigured Home Assistant node via its REST API.  If properly configured such a node could reduce the number of errors arising from improper indentation or other formatting errors arising from users making changes to the script directly.  

  Most importantly, such an integration would immediately open up new cross-platform connections as users would have their pick from any one of HAs components, NodeREDs library of flows or user-created nodes on NPM.

  This is just one example of course as there could be any number of integrations possible via MQTT, REST API, etc...

  

  Has anybody else had any experience with NodeRED?  Are there any immediate drawbacks to such a proposal that I'm overlooking?  I'd love to hear what others think either way!

  

[Andrew Jawitz]

For those who might be interested...  As of very recently NodeRED comes PREINSTALLED WITH RASPBIAN JESSIE!!!!  Unfortunately, this feature wasn't available a week when I tried installing Node.js manually and it created all kinds of errors.  I've been meaning to reinstall my HASS instance onto my RPi v2 anyway and made this happy discovery in the process of reinstalling Jessie!

[Andrew Jawitz]

Sorry to keep bumping this thread but the subject matter just became a heck of lot more relevant now that NodeRED ships with the default desktop for Raspbian Jessie as of 11-21-15.  As HASS also requires Jessie to run on the RPi this means that any new HASS install on an RPi will be alongside NodeRED whether you like it or not!  From my POV it makes a lot more sense to find ways they can work together than to force a choice between one or the other.

Perhaps the best approach would be to create a HASS node using the HA RestAPI?  Any thoughts?

I'll go on record as of 11/30/15 that somebody else will bring this up again within the next two months...

On Tuesday, 24 November 2015 14:36:27 UTC-5, Andrew Jawitz wrote:

[Paulus Schoutsen]

They could def be set up to work better together. Be able to call services/set states from NodeRed and be able to push data into NodeRed from HA. But then, these things can already be accomplished using MQTT as a broker in between.

I don't see NodeRed/HA as a holy grail. I think it will cause more confusion for users in the long run. They need 1 place to configure things, 1 place to control things and 1 place to check if things go wrong.

If we're not the right choice for some people, that could be something we might want to work on. Or not. People have preferences and we might not be their taste and that's fine. Home Assistant does not exist to be the perfect fit for every type of user - that is impossible.

Paulus

--
You received this message because you are subscribed to the Google Groups "Home Assistant Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to home-assistant-...@googlegroups.com.
To post to this group, send email to home-assi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/home-assistant-dev/30e3bd24-126e-44a0-99ee-26c1b6c90505%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andrew Jawitz]

Thank you for the reply as my intention is merely to start a discourse over a topic I'm willing to bet will be coming up more often... 

They could def be set up to work better together. Be able to call services/set states from NodeRed and be able to push data into NodeRed from HA. But then, these things can already be accomplished using MQTT as a broker in between.

I agree with the sentiment, but I still think NR and HASS belong in two completely different categories and therefore have different uses which can be used to complement each other.  NodeRED is first and foremost an interface and has become popular because it blurs the boundary between user and developer.  HASS has a lower barrier of entry for non-developers because it uses Python but there is still a clear distinction between those who have the skills to actually contribute code and components and those who are simply users. So if the NR UI already lowers this barrier, why reinvent the wheel?

 

I don't see NodeRed/HA as a holy grail. I think it will cause more confusion for users in the long run. They need 1 place to configure things, 1 place to control things and 1 place to check if things go wrong.

If anything has the trappings of a "quest for the Holy Grail", its the notion that anything will ever be the mythical ONE PLACE where everything is compatible with everything.  The ship sailed on that ever becoming a reality once every player in the home automation scene decided that THEY would be THE ONE PLACE to rule them all instead of working out more flexible interoperability standards. As a result confusion is now more the rule than the exception.  The best solution at this juncture is to become as flexible as possible and the user/contributors will recognize that flexibility as they create their own  ONE PLACE where they configure, control and debug....

If we're not the right choice for some people, that could be something we might want to work on. Or not. People have preferences and we might not be their taste and that's fine. Home Assistant does not exist to be the perfect fit for every type of user - that is impossible.

This sounds like something I would say if I put a lot of work into something and somebody came up and said it wasn't as good as something else...  Which has not been my point at all!  My point is that NR and HA are far from being competitors in the same space, but rather two very different tools with potentially complementary capabilities.  Where there may be overlap as with MQTT, then nothing more need be done.  My interest is in the areas where they DONT overlap and IMHO that area is in the UI.

Again, the only reason why I started really pushing this topic is because NodeRED is now a default program on the Raspbian Jessie desktop.  Since HASS requires the same OS to run on an RPi, this makes it very likely that users will be running HASS and NodeRED side by side.  Don't you think it would cause more confusion to have two completely disconnected platforms doing the same thing?  If instead we find ways to use the best that both system have to offer, early on, then everyone will win in the long run!

That is only my opinion of course and as I said my goal for this thread was simply to generate discussion so I thank you for your reply and encourage anyone else to reply with their thoughts.

To unsubscribe from this group and stop receiving emails from it, send an email to home-assistant-dev+unsub...@googlegroups.com.

[Aaron Johnson]

I have been learning/playing with Node-RED here lately.  Mostly because I've been messing around with IBM Bluemix and NR seemed like a stepping stone into it that I could manage.  

I'm no expert... My thoughts on this discussion are just that NR might be something a person could use to extend capabilities but I don't really see any necessity for HA to have to do anything to facilitate NR. A user may be able to employ what is in NR to extend home automation or what they are putting into or getting out of HA.  

NR might be a tool in the home automation arsenal but Home Assistant does need to do anything different because of that.  NR seems capable of using APIs to put in or take out data from HA (and other available APIs).  But, I might be missing some of the point of this discussion.

Another thing aside from NR that has caught my attention is Freeboard and Dweet.io.  Once again, to me HA doesn't need to change at all if I want to try and use those tools also, but I might use HA's API to get information to display on Freeboard or something.  These are just things I am looking at.  Whether I will actually do anything worthwhile with them is to be seen.

There is so much going on, some many technologies, protocols, products, it is overwhelming.  I'm just enjoying checking this stuff out but it takes so much time trying to learn learn learn.  HA is great because it has good documentation, it is actively being developed, it is free, people will help you, and I can understand it enough that my home automation is so far doing what I want.  The other stuff is just to try and experiment or keep up with change.  I will admit, node-red is an interesting way of working the Node.  Bringing in the graphical component, and the input - output design is pretty cool.  I also like that there are additional Nodes that can be added although I've had difficult with a number of them (getting them to work).  Another thing that is neat is Mapbox.  I've been trying to use Google APIs like Places and Distance, Mapbox, Openroadmap, and NR to make my own maps that let me see where we are by our MQTT Owntracks data, plus create custom map views, and get info like how far away my wife is from home, or be able to ask my Echo where she is and have the Echo give me a nearby landmark, intersection, direction of travel, or distance from home.  Sorry I like to talk about this stuff.

later,

tobias.

[nzfarmer1]

Agree about the two products being complementary.

We are considering keeping putting both NR and a customised version of HA on our embedded device for NZ farmers.

I can see a scenario where we use NR nodes to generate the configuration.yaml automatically - essentially using a hook whenever node-red loads to regenerate the config and if necessary restart HA.

NR also provides us with the notification/routing framework - emails/SMS/3rd party integration.

Definitely complementary.