I think the Jetbrains IDE's might all might support JS/HTML as they tend to be so common part of any "full stack" development these days. But given the fact the all-products-license is so cheap I've went for it. Just in case I want to try Golang in addition to Java/JS/C/C++. I think the only advantage of Webstorm is the focus on web/JS things with a little different project wizards and such.
This is likely just "normal". I don't think I've ever seen a clean warning free node-gyp build.
Edit: if there's actual errors and not just warnings then it might be a good idea to just paste the errors to Google.
I wasn't having a go. Apologies if that's how it came across.
That is pretty far from the original topic discussing hardware support.
I was trying to point out that as you have moved from discussing software support for particular hardware to building node-red, that the relevant & experienced folk might not see your posts asking for help.
As long as you remember that, mostly, the experienced folk are also the busiest in life, family and work and we've already noted that what you are wanting may not be everyone's focus.
These days, Node-RED is so popular and the forum so busy that few have the time to attempt to follow everything, certainly I don't sadly.
If you want to create a node-red node you don't need to build node-red itself.
Start here Creating Nodes : Node-RED
Perhaps I have misunderstood exactly what you want to do though.
I now have a working fork of master within my IDE is that not a good starting point ?
My approach is designed to be a minimum burden on the community.
The plan is to see if I can single step into a working node and then create my own from an existing MCP23017 and try to detach it from I2c calls as a first step.
A clone of what exactly? I haven't been following every single reply in this thread - there are now 92 posts. Scanning back through, I can't see you mention which git repo you are cloning - my apologies if I've missed it somewhere.
You don't need a clone of the node-red source code to start developing nodes. You can install and test nodes you are developing with a regular install of Node-RED.
Are you following the Creating Nodes guide? It won't go into the sort of depth you'll need eventually, but it's a good place to start as you're new to this environment and particular set of technologies.
I forked master and cloned that. Now I can mess around as much as I like and revert the mess ups.
It may not be necessary but it is done. I feel comfortable with JetBrains it has git built in. I can now keep in sync with master. Hey there could well be another version by the time I have got a hardware node working.
Also If I have working source I can see where execution goes with working code. Also navigating is incredibly easy. Plus knowing what issues exist, maybe have a go at fixing one. And just browsing the code !
Time is too short to be debating IDEs. It works. Shoul I shove off to another category or what.
Thank you that looks good. The problem is maintenance. If it is not part of node-red distribution it will die by not keeping up with node version changes.
I propose a small collection of hardware nodes that expose a chips functions but communicates via MQ (as others have described). It may have to be a little prescriptive in determining the serial format to and from the device but as long as it exposes all the chips functions and responses then that does not matter at all and is never going to change or be made redundand by node (what I would call a static definition).
If a small collection is too big a burden then a single example should at least use check boxes, drop down list selection etc. rather than a singe temperature measurement for example.
One of the most important reasons why I think it should be kept totally separated from NR development & distribution, such "strong bindings" should be totally avoided. Instead such devices should be either INTEGRATED via a standard protocol like MQTT or they should be a device connectable to a usb port. That will make each part rather independent of each others. Imagine you have to follow and sync, having the same release dates as NR, a nightmare. Maintenance can instead be focusing on features (and ev bug fixes and user documentation!) and releases can be made freely without dependencies.
A very nice product series based on the cheap ESP device concept, using also MQTT over WiFi, is Shelly. So smart, simple to configure and operate, lots of features I personally don't need and they simply work. Reliable.Very clever design as well. And very competitive pricing, cheaper than ZigBee and much, much, much cheaper than Z-Wave devices
PS I don't use their cloud, I have everything just internally connected on my network using my own MQTT brokers
The specification of a chip is static and will never change without a part number change which does not happen anywhere near as often an node version changes.
Lets say a chip has two command registers and some device address bits. The difficult bit (for me at least) is creating a UI to those settings. The UI should allow address selection and data input fields for those command registers that get serialised and sent to MQ.
The chips responses are also fixed and will not change and so if the serial format of the reply is prescribed by the info page within NR then it can decode the response.
The maintenance problem has gone away (as far as the NR dev team is concerned). The developer/end user then chooses the hardware for the controller of the device (arduino or whatever) and unpacks the address and commands from its serial in, talks to the hardware (they should be good at that because that is within their comfort zone) and serialises a response in line with the info provided within NR.
So the strong binding is only against the chips functionality, and that will not change over time.
By all means say if it is a daft idea but please explain why ?
The core Node-RED nodes (the nodes you get when you npm install node-red) are domain neutral. They are not IoT specific. They are not hardware specific. They provide basic programming building blocks and are useful for all users of Node-RED.
We will not add hardware specific nodes to the core Node-RED module.
The Node-RED project (by which I mean, the Node-RED organisation on github) maintains a collection of extra nodes - GitHub - node-red/node-red-nodes: Extra nodes for Node-RED. This includes the Serial port node, the pigpiod nodes, the Pi Sense Hat nodes. They are all maintained as separate modules and can be updated entirely independently of the release cycles of the core project.
It is exceedingly rare for a pure JS node to need any upkeep due to newer versions of Node. The issues tend to be where nodes require C code that has to be built for newer versions of Node. An ideal model is for the Node-RED node to make use of existing well-maintained low-level libraries - as those libraries will typically have a much larger audience than just Node-RED. This is why some of our existing nodes lean on existing python libraries - its simply a pragmatic way of getting things working.
If the node has a maintainer who is interested in maintaining it, then it won't die. If they lose interest in it, the community can step in.
The key point is, at this point in time, its fairly irrelevant as to whether the code ends up in the Node-RED organisation on github, or someone's personal account. The question is whether there are people willing and able to do the work and take on the longer-term effort.
I speak from bad experiences of nodes being contributed to the Node-RED project on github and then getting abandoned - leaving Dave and I to add it to the long list of things we have to maintain.
