I do.
http://www.hitachi.co.jp/New/cnews/month/2017/08/0809a.html
Several more, but these give starting points.
2 Likes
Is it not evident from the survey results ?
There is no getting away from the enormous pi user base. NR is there already which is the hardest part. I think the peak interest and diversity of hardware nodes came a little too soon for the host hardware. I, like many others I suspect were waiting for the next boost in pi performance before revisiting hardware nodes in NR. Now we have the Pi4 and Pi Zero and 8GB RAM but it looked like hardware nodes were going to fall by the wayside.
Yes the Pi is a very popular platform and Node-RED running the Pi is a great platform. Yes a large proportion of users who engage with the forum are using the Pi for personal projects.
That does not reflect the large number of users who use Node-RED in the various commercial products and solutions that embed it. In my experience, those users don't tend to engage with the Node-RED Open Source community directly. But we do have discussions with those companies and contributors, not always in public spaces, in order to help gather requirements and get feedback for the project.
I don't think anyone would disagree with the statement that there should be good quality nodes for different hardware devices.
Once I again, I ask that rather than debate the ephemeral, let's turn it into concrete suggestions for action.
Node-RED is a community project. Nothing happens without time and effort coming from the community.
3 Likes
Nor me, I just wonder about the long term success here. If there is not going to be a working example of a hardware node that is part of the default installation on a Pi then I think many users will find it difficult to create their own and thus prevented from giving something back. My case in point. I ended up using exec nodes which is a terrible way of handling real-time I/O.
This was only in response to your observation that unprotected 3v3 tolerant I/O is fragile. If your test bed is equipped with buffers you can save your Pi and dispense with the buffers when fully tested.
A different approach, but thereās many roads leading to Rome. If real-time I/O is this important for your use case, have you thought about running directly on low level (for example the aforementioned C/C++ bindings), and communicate from those programs with Node-RED through some of the widely supported protocols? For example thereās a group of users on the forum demonstrating they prefer running sensors on ESP8266 devices and have them communicate with their Node-RED system over MQTT. That doesnāt mean you should use ESP8266 instead, but you could interact between low level tooling that has proper real-time I/O (as opposed to JavaScript) and Node-RED, even on the same device, for example through a protocol like MQTT, or even raw TCP sockets if you were to prefer that.
3 Likes
Thank you for the help. I just wanted to keep the hardware to a minimum. The pigpiod library is very mature and js would not be detrimental to its accuracy or reliability. I however am getting quite long in the tooth and do not really have the time or the inclination to reinvent the wheel and do exhaustive testing on low level I/O.
My fault, finger trouble. I was giving an example where I used moment to format a date and found that it pushed the system over the edge. This was info for those that think the Pi Zero cannot run NR.
Thank you, will take a look.
For what it is worth, there is a collection of sensor nodes for the Raspberry Pi
and a collection of all nodes for the Raspberry Pi nodes
If you find one I've missed send me a PM and I'll add it.
2 Likes
Does anyone think that? I think that a Zero is about the same power as the original Pi isn't it? One of those was my first Node-RED platform. Just don't try and run a Linux desktop as well 
Certainly it should be able to run a decent set of Node-RED flows plus an MQTT broker. As long as you don't try and handle some massive data at least.
Interestingly, in theory, it should be possible to run Node-RED on an ESP32 if you could get enough of the dependencies to run. Power-wise it is certainly powerful enough. Not presenting that as a serious option of course, an ESP32 is an embedded microprocessor for real-time IoT, a Pi is a Linux single board computer (a general purpose computing unit running a desktop/server OS). Which is also why an Arduino or ESP or PIC device is much better suited to GPIO than a Pi will ever be. Not putting down the Pi, it has done incredible things for education and IoT adoption/exploration.
It is only a single cpu and can become unresponsive to and unable to deploy because of the backlog of waiting tasks I suppose. I thought one comment sited lack of power on a 4cpu pi which is why I mentioned bloatware. I too experienced saturation when python libraries were used. Just as a softie may misdiagnose a hardware problem a maker may misdiagnose a software problem. It took me a while to realise that a single statement I had used when debugging a large flow was now contributing to the struggling app and preventing the fix of other issues.
I now include a flow with cpu load, temp, ram and disk available so I get the heads up on resource depletion. This approach has saved a lot of time and when you have fixed any bugs the flow can be removed, allowing a little more headroom.
The Pi Zero has an ARM1176 processor the same as the original Pi which, as I said, is perfectly happy running Node-RED as long as you don't overload the memory or storage I/O. I thought that the 1176 was 4-core not single core. In any case, node.js is largely single-threaded.
The main bloat on Rasbian and related OS's is the desktop. As long as you disable that, it is fine. Not having unnecessary nodes installed in Node-RED does, of course, also reduce overheads and you really do need the GC override when starting Node-RED to encourage the GC to kick in at 256MB RAM. GC is much more likely to pause your flow than any pipeline blockage I would think.
That is likely to be a reference to electrical power which the Pi's are fairly notorious for being a bit picky about even on the Pi 4.
Of course, one of the issues with Python is that it is, I believe, even more single-threaded than node.js because it is not designed with an asynchronous process model like node.js is. Once you start your Python code, it is going to lock everything else out of that process until it finishes unless you are using one of the 3rd-party libraries for async processing. node.js's inherent loop allows the appearance of async processing on a single thread.
Actually, I do that outside of Node-RED so that the reporting isn't dependent on it. I use Telegraf, InfluxDB and Grafana. Not a set of tooling to run on a Pi Zero of course! 
Though maybe Telegaf would be OK with reporting out to InfluxDB running on another device.
So that is what rust looks like. That certainly puts me well outside of my comfort zone. I am sorry to admit that I would not have a clue how to give this a front end in NR. But also I do not have much of a clue how to create a front end to any library for that matter or I would have tried.
There was no destop (raspian lite I think I started with). Managed via ssh. I also used the 256MB arg when launching NR. Sorry do not know GC . Garbage Collection. The main problems were python, moment (for what I was using it for it was massive overkill) and a couple of others that I cannot recall now. Also I found 384MB more satisfactory in my case.
Whatever the cause the browser would time-out several times and take quite a while to catch up.
Yes I think most Pi users are aware of that. However my first designs had complete disregard to resources, lots of execs to hardware python scripts and fancy js libraries were capable of bringing a Pi3 to its knees.
Yes Influx and Grafana are amazing. Thanks I will look into telegraph.
I would agree to this, so convenient and simple, reliable and efficient standard interfacing with NR via MQTT, now also supporting MQTT over SSL. Just works so fine!
Hi there, just reading up and thinking out loud...
Isn't it better to keep the low-level development stuff separated from NR itself and instead join forces with dedicated communities for sensor integrations? Skilled C/C++ developers will be able to develop smart & compact solutions for their sensors. Check out here as example what amazing stuff they have achieved: https://esphome.io/index.html
This is only one example, you have Tasmota, ESPEasy and others.
Personally, I prefer to use some ESP32 devices instead of wiring things to my RPi's. Gives me also better freedom when distributing sensors, no need to have wires all over the house, just connect power unit to closest power outlet. Still having the option to run a wire from the ESP32 to the sensor. If needed
6 Likes
Using ESP32 what would an MCP23017 look like from within Node-RED ?
Would one have full access to the device for example individual control of which ports are active high,low or open drain ?
that would depend on how you program the ESP32, but yes, that is possible.
You can connect them via MQTT and then publish to topics like deviceName/control/port4 or what ever and have a payload of high to turn it on.
Of course you would then be limited in the rate you can turn these pins on and off, but fast stuff should be done on the microcontroller anyway.
