Clean up palette and enabling projects

[hklages]

First of all: Thanks a lot for that amazing add-on. I was able to move from pure Node-RED to "Home Assistant with some Node-RED" in a few weeks. Most of my routines are now in Home Assistant - some specific ones still in Node-RED.

My 2 suggestions:
a) enable projects in the add on configuration. Projects are fantastic and in my opinion every one should use it. So making that available in the config would make it easier to start with.

b) clean up palette
The basic Node-RED installation has rbe and tail. I suggest to add node-red-contrib-home-assistant-websocket (plus those nodes not being installable via palette) and leave the rest in the responsibility of the user. It is so easy to install with the palette and the user knows best, what he wants and when he would like to update. That would also simplify the maintenance of this add on.

Right now there is installed:
node-red-contrib-http-request: depreciated as there are build in nodes
node-red-node-sentiment: that used to be in the base Node-RED base but was recently removed. Does anyone uses that?

Many overlapping packages for time management where Home Assistant in combination with JSONata + $moment() could do the job:
node-red-contrib-bigtimer, node-red-contrib-sunevents, node-red-contrib-time-range-switch, node-red-contrib-timecheck,
node-red-node-suncalc, node-red-contrib-moment

Many nodes, where Home Assistant can provide a solution:
node-red-node-email, node-red-node-feedparser, node-red-node-geofence

[frenck]

Projects are fantastic and in my opinion every one should use it

That we had once, and was reverted because not everybody shares that opinion. You can turn it on if you like.

and leave the rest in the responsibility of the user.
It is so easy to install with the palette and the user knows best, what he wants and when he would like to update.

Sounds sane, but not how it works. For example, not all dependencies can be build on the fly and when the OS has changes in the add-on, compiled nodes might actually become incompatible and thus the add-on would not be able to start anymore.
Thus, it is the way it is right now. Additional nodes should be managed via the add-on configuration, not the UI.

JSONata + $moment()

Many ways to rome.

Thanks for your feedback.

[hklages]

Sounds sane, but not how it works. For example, not all dependencies can be build on the fly ...
None of the packages I mentioned have to be compiled. Compilation is only needed for a few like modbus or serialport. So cleaning up would be possible.

What's is the reason, why you recommend to install via add-on configuration and not the UI - because of the compilation or are there other reasons?

[frenck]

Yep. So compiled can be linked against libraries that are no longer compatible or available with the next add-on update.

[hklages]

So the recommended way to add new nodes is to use the Home Assistant Node-RED Add On configuration.

Just an idea:

Would it make sense to use this procedure also for the included packages such as node-red-node-sentiment (except for the HA websockets integration)

Advantages:
a) every user is able to configure - add, remove, replace nodes
b) no breaking change
c) good example how to do that and demonstrating that this is the recommended way.

Additional comment to my initial comment regarding Moment

Moment.js is a legacy project, now in maintenance mode. In most cases, you should choose a different library.

So unfortunately also the JSONata approach (as the custom node) may vanish.

[frenck]

It think it is fine as it is. Thanks for the feedback though.