Can you come up with a direct example why they would want to do so (i.e. creating a GUI front end, as you call it)? I've plenty of low level hardware that I don't want to interface directly with Node-RED. I see no need to create nodes for it to interface it with Node-RED, when I can control it through a different manner, for example through MQTT. I've written a couple of those "GUI front end" custom nodes, but I only do so if it's too complex to handle it directly in the flow by putting existing nodes together to handle the logic, or when there's no other solution.
Why the need to reinvent the wheel (with a "GUI front end/GUI interface") for every single piece of hardware, as opposed to other solutions? Every single interface like this means additional maintenance. While the Editor side interface is pretty stable, it still means that this part of the code needs to be carefully checked too at times. That's not a no-code/no-maintenance solution, and appears to be more overhead for the maintainer for those nodes, when on top of that the user of them has to write code too for their device to interact with such a node.
A one second 10 byte msg is not in my opinion an overhead. The GUIs for the chips are already written but bound to hardware drivers. Create a new set and class them as remote devices.
This is a hardware agnostic solution. As long as the target can read serial in and write serial out it will be happy.
If code is linked to the pigpiod_if2 library it does not need root. I know it works in user space because that was one of my ugly work arounds.
Precicely. Once you publish the current hardware nodes (GUI with no hardware driver bindings) as remote (msg out msg in) nodes and there is uptake of the concept then get rid of that hardware driver millstone for good. Best left where it is in the target.
Again publish remote devices and eventually drop all hardware drivers from your maintenance responsibility.
It has to be easier to remove driver linkage from the front end of existing chips and publish then as new remote devices rather than working on exposing I2c/SPI in pigpiod. It they do not work at the moment their interface is still valid.
The bigger picture is getting away from hardware drivers and maintenance headaches. Also becoming target hardware and software agnostic.
A few lines of stub code at your end and out of the box is maintained.
The only thing the maker has to do to get a nice GUI front end and connection into the NR world of services is to modify working example code to read a string and write a string.
Well sorry I tried my best. There is no comparison between the dev effort required by a maker to build and debug the chip GUI and modify a few lines of example driver interface code. They do not even need to consider I2c/SPI for that matter because device library code abstracts that detail out.
That "GUI with no hardware driver binding" will still need maintenance too, especially if you have to write one for every single piece of hardware that you want to support. Something to keep in mind.
Creating a separate node/module for multiple different hardware devices will lead to a support nightmare. Some will be maintained by people with an interest in that specific device, but many will fall by the wayside.
My day job involves writing device drivers and maintaining a complex API, and wherever possible we create commonality between devices, precisely for this reason.
Well you don't seem to have much concept of the effort involved nor of the amount of interest.
Spending a few minutes reading and discussing ideas is a massively different undertaking to that of interfacing hardware and software - especially when both are complex and there is a complex OS in the mix as well.
This really has nothing to do with experience of hardware or software, there is plenty of both in the forum. It is a matter of cost vs reward. Everyone is already finding a cheap way around the issue by avoiding it altogether using cheap microprocessors with free, open source, well maintained software (with their own active communities) that avoids the need to do any programming, only configuration.
Even beginners find this easy enough, especially with the help from forums like this and those of ESPEasy, etc.
Editor node that spits out a config/command msg whose response msg is used within the flow and updates the status of the editor node.
Consider individual chips as sources of Iot data input. Some may have a very simple or near nonexistent UI (just two connections) config/command in, response back from target out. Others require a larger interface for configuration.
An aduino could be considered as a chip at the NR end but it would be a bit over the top to expose its I2C/DMA/PWM/AtoD etc. But simple GPIO like the current pigpiod would be easy and very useful in its own right. In this case at the aduino end the code to read msg in, read/write GPIO and send msg back would be trivial. And hey no hardware library to wrestle with.
I must be really stupid then because I could not write an editor node and link it into a hardware library under NR.
Yes so no need for hardware drivers compiled against editor node code.
My design is finished and stable. I chose chips that already had an editor node and the most recent node version that ran was 8lts. All done dusted and forgotten. I cannot open pallet manager and use a 23017 (just as an example) with the latest lts version of node. and get a working out of the box experience. And I see that is an ongoing development nightmare.
It would be illuminating to see a list of editor nodes that all work against the latest node lts.
Nor should you want to assuming that you are meaning a Dashboard widget. I don't know why you would want to tightly couple Dashboards to hardware. If you want that, then there are lots of other tools like HA.
Note-RED is a low-code development platform. The Dashboard is designed to create end-user Dashboards not technical hardware interfaces. It can do that but that isn't what it is aimed at.
You've lost me (and I suspect others) here because in the previous para you seem to want to link Dashboard to hardware.
Hardware connected to a Pi is better served by creating interfaces at the low level that expose high-level standardised API's that can be consumed by any code. This is not a job for Node-RED. I'm getting a feeling of deja-vu now.
We look forward to the results of your exploration.
I believe not. The chip function is completely static (number of pins, read registers and write registers etc.). So in the editor node info page you specify the format of the input msg and output msg. Again this is static.
Once the editor node is tested it cannot break because it is just javascript right !
If it did then probably all editor nodes would likely break. But it will not break due to hardware driver code because there in none. No external hardware libraries to worry about and completely target agnostic as long as you can get a msg to and from the device.
Wrong. Widgets rarely stand alone and often are dependent on underlying libraries. And you've already noted (what started this tortuous discussion in the first place) that JavaScript itself also changes - very rapidly and quite dramatically at times. Widgets also operate in the Browser which also changes - rapidly and dramatically.
If you want static software, JavaScript is one of the last languages you would come to. This is one of the main reasons for programming in C/C++ (as an aside, also one of the main reasons that the venerable Fortran is still in wide use - a significant amount of Fortran powers various Python libraries too - it is fast and stable).
I don't. Your having a laugh. Why are there dozens of editor nodes that do not work ? I suspect it is precicely because they are bound to hardware. Get shot of that hardware library coupling and allow those editor nodes to work on any embedded target platform (unchanged). The editor code code already exists.
Again you must all be having a laugh. I have never said such a thing.
Me to. So why do you do it. Create nodes for the Pi for example.
So nobody knows already I am shocked. They should not be published if they do not work.
My confusion is once again increasing. Can you answer the following question on your idea of a "GUI front end". I've added screenshots with examples, and the common name within Node-RED development for each of these. Can you explain which of these you mean?
A node's configuration screen within the flow editor:
A dashboard widget with the node-red-dashboard node as seen from the dashboard that can be interacted with, for example through clicking a switch/button or entering text in a form:
There is the problem 'they rely on underlying libraries' when they need not (hardware libraries that is).
There is no comparison between widget breakages caused by external hardware libraries (one for each of the myriad of target Iot hardware platforms) and breakages caused by node bug fixes. Someone said that a node version change should not break plain old javascript and I agree.
Sorry wrong interpretation on your part. I mean static functional definition.
Oh just like you can get really good database performance using Cobal.
Seemed that way to me given the language. "Dashboard widget".
Which ones? You've been repeatedly asked to list some so that we can get a better idea of what you mean but as far as I can see, none have been listed.
Are you really talking about Dashboard widgets here? Why would any of those be linked to hardware, that doesn't make sense.
I think you are talking about Nodes? That is totally different. Even so, which ones don't work? Dozens? Please list some otherwise this conversation is going nowhere.
I don't. That there are some Node-RED Nodes that do is indisputable. Most of those are written by contributing authors. Node-RED, being open source and a platform for all to use, has no control over that. There are a few core ones that have already been moved to a non-core location as Nick has already pointed out. They mainly came from the early days of Node-RED when it was primarily a showcase for the excellent brains at work in IBM. A long time ago in a laboratory far away.
I'm sorry, maybe it is because this is a Friday afternoon after a long, arduous week but I find that highly insulting to all who have spent hundreds if not thousands of personal, non-paid hours of effort making Node-RED into the massive success it is today.
They doubtless worked when they were published. Things have moved on and the authors haven't. Tough. That is the world of open source. You are free to pick any of that code up and make it work - preferably with the blessing of the original author but if not then you are still free to do whatever you like. But I'm afraid you seem to be suggesting that others do this work when you are not prepared to.
Everything is about demand and supply. Seems you need this specifically but the supply is not there so there must be some reason. If there was or will be a high demand for something I'm sure the supply will be there or would be already.
So what to do (for you)? If your need is for private reasons, you can decide to walk the talk, learn how to develop nodes. Reading and trying, looking into existing nodes code, etc. Sweat & tears. How many hours do you think other node developers have spent before they became masters of the thing? See it also as your personal development and feel the joy one day when you proudly can contribute your babies to a grateful community. If it instead is for commercial use, well pay the bill, hire some software consultants and join the ride, it is actually also pretty interesting, just my own experience
:sigh: not sure who said that but I'm afraid that it is a nice idea but totally impractical. Just as it is impractical for you to expect that you could install Linux on a device without updates for months and expect to install new software on it.
If you want code that works for years with no changes, you have to write in a low-level code language that is highly stable. That is why hardware interface libraries are better written in low-level languages (in addition to the performance). I've tried to say this several times now but it doesn't seem to be getting through.
No, it isn't. A static functional definition doesn't help at all if the underlying platform changes in ways that couldn't be predicted. This is a problem for all languages but particularly so for dynamic ones such as Python and JavaScript and doubly so when so much code is dependent on 3rd-party libraries. This is a well understood issue.
If you mean COBOL, what has that anything to do with it? Fortran provides up to 30% or so of the code in some Python libraries such as SciPy. Because the code was written decades ago, is fast, stable and just works. Loads of engineering and science is still done using Fortran.
To clarify. By 'static functional definition' I mean all the characteristics of a chip are static and will never change throughout the life of the chip with out a revision number change. These revision changes are more like voltage/current or small timing changes. There would not be a functional change to the operation of the chip like change the address of a register or changes to status bit positions or commands or anything that would alter the function of the device.
So an editor node for a chip, once formed and tested need never change for the lifetime of the chip. That is why I used the term static. Nothing to do with language constructs or under lying hardware just a static definition of the functional/physical characteristics of the device.
As long as the editor node sends a correctly formatted msg to the device and correctly decodes the msg response from the device then the underlying hardware cannot have any influence over how the editor node works unless the problem kills serial comms but then you can timeout if the response fails to arrive on time.
I really did think you were having a laugh with the responses that came back from my accidental use of the wrong name. I am really sorry to all.
Do you know how I can correct those quotes and wind this back to sane level ?
Cobol, I was taking the mickey. Yes I know fortran is still used extensively. Wave propagation theory used miles of it.
If only that were the case. I am three score plus and life is too short. Going in for angioplasty next week.
I have spend 5 days I did not intend. I do not begrudge that experience in the slightest.
I forked master and built NR (even though I did not need to) so I could easily jump around the code and try debugging working 'editor nodes' in my favourite JetBrains IDE. I just ran out of steam which is a big shame because I know that any one here worth their salt in web dev could copy and convert these existing editor nodes to new ones that do not talk to hardware drivers but instead simply parse in and out messages. Half a day I recon for a whole bunch of them. 10 minutes for one I bet. But sadly not me !
For the record I am retired and have no commercial interest in any of this whatsoever.
