Clumsy, complicated...

  • Hi,
    I really appreciate your effort to develop "official" nodes for node red. My initial reaction was really WOW! I have been using Node Red for almost a year. I am not a developer, I can not write my own code and Node Red helped me a lot in integrating Neuron into my home automation. I rely on node-red-contrib-unipi-evok which is great but unfortunately no longer maintained by phillipsnick and I am happy to see you guys taking over the mainetance of node-red-contrib-unipi-evok...


    Your new nodes are a step back from the "unofficial" node-red-contrib-unipi-evok
    by phillipsnick ( Here are my comments:

    • Why did you build only "filters" and not standard "input" and "output" nodes? Node red is supposed to be "very intuitive and user-friendly". Standard "input" and "output" nodes are intuitive. However, your "filters" are not very intuitive.

    • Since your nodes are just "filters" (and not standalone input/output nodes), they require connection to websocket node. Which makes the whole flow more complicated (more nodes, more connections). Standalone input/output nodes are better - at least from user point of view.

    • I really miss the "fetch available relays / outputs / inputs" feature. The old nodes by phillipsnick were able to automatically fetch all available devices. One could simply pick relay / output / input from a drop-down menu. Now you need to copy-paste the name of the relay from Neuron's WebGUI... This is very user-unfriendly and a huge step back.

    • I really got lost in all those "circuits" and "devices". Your new nodes look like some kind of "barebone" GUI for existing websocket. A very simple transposition of the websocket syntax into a GUI. I really think that you should not bother Node Red users (who are looking for intuitive and user-friendly tool) with some "devices" and "circuits". They would like to see intuitive UI with "relays", "inputs" and "outputs".

    After two minutes I was like OMG! How can I get back to the old nodes? Because you did not bother to rename the nodes, I had to delete all nodes by phillipsnick and uninstall the old node-red-contrib-unipi-evok package only to test your nodes. Re-installing phillipsnick's package was also a challenge. It is no longer available in "Manage palette". Thanks god the old package can still be installed manually by npm i node-red-contrib-unipi-evok...

    Anyway, I really appretiate your enthusiasm for Node Red (which I share!). But I only hope that this was just some kind of prematurely released alpha version and more serious development will follow either by you or by your young colleagues from Beroun... At the moment, I stick to the old package by phillipsnick. My house depends on it....

    P.S. On a more technical note, I am flooded with "SyntaxError: Unexpected token e in JSON at position 1" error messages.

  • administrators

    Hi @budulinek,
    thank you for such detailed description of your rather unpleasant experience.

    The original idea behind creating our very own nodes supporting our PLCs, was to be able to be fully responsible for the development. We could reuse the Nick's code, since the MIT license, under which he released the code, permits that. But we weren't able to contact him to discuss this, so we rather build it from the ground up.

    Why did we build only filters and not standard input output nodes? The reason the unipi-input needs data from websocket is to make it more versatile. Probably the most common scenario is to have Node-RED running directly on the PLC and therefor the websocket URL could be hardcoded into the unipi-input and we wouldn't have to bother you with the separate websocket node. But that would make it unportable. Think about different scenario, where you have multiple PLCs in your network and you want to run the logic in Node-RED only on one of them and control the rest of them from there. Or a different scenario - you don't want to run the Node-RED on the PLC at all, but rather in some virtual machine where you can give it more resources and probably run it together with InfluxDB and Grafana. In both of these examples, the hardcoded ws URL wouldn't work. That's why we decided to have input node receiving data from the websocket node and output node sending data to the websocket.

    Another reason why we have nodes which filter data and you need to select what do you want to filter, has its roots in the versality. You can configure Evok to read 3rd party devices via ModbusRTU. It would be complicated to express this type of data via dedicated input nodes.

    We realize that the Node-RED and nodes itself should subordinate to the ease of expression of ideas and the versatility in many cases goes against that. The biggest "awkwardness" of the current setup probably lies in the missing autoloading of the list of IOs. We miss that feature too and I can assure you that we will include it in the future release.

    And now for the migration from Nick's nodes to ours... Yeah, we didn't make it any easy by naming the nodes the same way as Nick's. The transition to our nodes is complicated and once the Nick's package is removed, it's hard to get it back. That's fully on us and we do apologize...

    The current release is really more of a MVP and there is a long road ahead to build it into well-thought, well-supported tool.

    Thank you again for your time you invested in giving us this feedback.

    Have a nice day,

    PS: Can you post your flow which causes the SyntaxError? I'll take a look at it.

  • @martin-kudláček said in Clumsy, complicated...:

    therefor the websocket URL could be hardcoded into the unipi-input

    Hardcoded ws URL??? You do not have to hardcode the ws URL if you want to build a standalone input or output node. Just have a look at Nick's node-red-contrib-unipi-evok. Or node-red-contrib-loxone. They both use websocket and the ws URL is not hardcoded. The ws URL is specified by the user in the so called configuration node.

    You can configure Evok to read 3rd party devices via ModbusRTU. It would be complicated to express this type of data via dedicated input nodes.

    OK, I got your point. But again, you can configure the device (whether it is a Unipi/Neuron/Axon or some 3rd party modbus) in the configuration node. No need to do that in the input / output node.

    Or, another common solution. Again, see node-red-contrib-unipi-evok for inspiration. There are actualy 4 nodes in the node-red-contrib-unipi-evok package. Input node, output node, configuration node and "unipi-api" node which (I assume) serves as a simple filter (I do not know the detaills, I have never used it). So you can always build input and output nodes for those who do not use 3rd party devices and a "filter node" for those few users who want see the full communication.

    Also, if you really need a filter node, one "bidirectional" node should do the job. You do not need two nodes. Just have a look at the built-in "json" mode. Converts between a JSON string and its JavaScript object representation, in either direction. I do not know how it works but it is somehow able to recognize what is being fed into the node.

    Can you post your flow which causes the SyntaxError?

    Sorry, I can not, because

    The transition to our nodes is complicated and once the Nick's package is removed, it's hard to get it back.

    I am ready to help you, but I do not want to uninstall Nick's package.