my-little-ui-node Issue & question

[Christian-Me]

Hi,

I'm just about to finish my first custom ui-node. The my-little-ui-node helped my a lot. Thank you.

But I miss an example how to get the state of the widget in sync with other clients showing the same dashboard / tab. Perhaps I miss something. Can anybody shine some light on the mechanism wow i.e. the slider is in sync on several dashboards. I think the same mechanism will make sure that the node shows the correct value when a client connects or reconnects.

And a little issue: When you install the little-node you will get 2 "shadow" types: "ui_yournodenamehere". If someone uses the my-little-node as a prototype and don't delete the comments on line 247 and 348 he can't install his one node due to duplicate types. This took me some time to recognize - sometimes comments can be quite active code ;)

.config.nodes.json

    "node-red-node-ui-mylittleuinode": {
        "name": "node-red-node-ui-mylittleuinode",
        "version": "0.0.3",
        "local": true,
        "nodes": {
            "ui_my-little-ui-node": {
                "name": "ui_my-little-ui-node",
                "types": [
                    "ui_yournodenamehere",
                    "ui_my-little-ui-node",
                    "ui_yournodenamehere"
                ],
                "enabled": true,
                "local": true,
                "module": "node-red-node-ui-mylittleuinode",
                "file": "C:\\Users\\cmeinert\\.node-red\\node_modules\\node-red-node-ui-mylittleuinode\\mylittleuinode.js"
            }
        }
    }

[dceejay]

by default a message coming back from the UI has a msg.socketid property attached. If that is then routed back to the UI then it will only go back to that socketid - if you delete that property it will go to all.

I'll update those comments to remove the < > in that example node.

[Christian-Me]

Hi Dave, thank you for your quick reply. When the user change the ui element a (new) message is sent via `$scope.send({state:color[$scope.config.outFormat]});´

It then pass `beforeSend´ on the backend:

                    beforeSend: function (msg, orig) {
                        if (orig) {
                            var newMsg = {};
                            // Store the switch state in the specified msg state field
                            RED.util.setMessageProperty(newMsg, config.stateField, orig.msg.state, true)
                            //orig.msg = newMsg;
                            var topic = RED.util.evaluateNodeProperty(config.topic,config.topicType || "str",node,msg) || node.topi;
                            if (topic) { newMsg.topic = topic; }
                            console.log('beforeSend:',newMsg);
                            return newMsg;
                        }
                    },

resulting in beforeSend: { payload: { r: 129, g: 120, b: 255 }, topic: 'colorPicker' }

So no msg.socketid at this point. Sorry I still don't get it.

Chris

If you like to know what I'm working on: https://github.com/Christian-Me/node-red-contrib-ui-iro-color-picker

[dceejay]

yeah - but what arrives in a debug node set to show all ? (And yes very nice - like it)

[Christian-Me]

As expected ... including the socketid But how can I get the dashboard backend to update other clients automatically. (like when I place a slider without any connections and use it on one client other clients follow simultaneously).

If I send a new colour from the flow to the node (without a specific socketid) all clients are updated as expected.

I was searching for a colour picker which is usable in different ways and on mobile devices for a long time. iro.js popped up in the forum from time to time and to be honest I hoped that someone else (with more experience) could do the job. In the end I was procrastinating other jobs and thought it would be a nice small project to learn how to implement a custom ui-node. In reality I was searching for a slider which could set a (or two like upper and lower) value and display the actual value by the bargraph. I have dimmers for my indoor green house which fade (very) slowly to simulate the sun over dark winter days. A combined setpoint and real value is useful for other actuators like heaters and valves too. This would a project for another rainy weekend (or two) - iro.js can do something similar by using the multiple colour feature which I will try out too

[Christian-Me]

After some (hours) of debugging I found it ,,, I already noticed that flag several times but never tested it until I reached ui.js with the debugger ... ;)

storeFrontEndInputAsState: true,

Now I only have to solve that loopback issue as the emitting session now gets its own message back. I somehow have to figure out if a message received in $scope.$watch('msg', function(msg) {...} originates from a different cession or the input of the node in the flow. If it is the own messages (in the meantime the slider may have already changed by the user) it should be dropped. (For me a cession should not get it's own message back from the backend - I already had that problem in ui-table and had not found a satisfying solution back then)

Should be solvable ...

[Christian-Me]

Think I fixed (most) of the tasks around my initial question. (I pushed the latest version to github)

I don't know if it is ok to ask it here but I ask it anyway ;)

Is it a good idea to stop sending new values until the last one is "confirmed" to avoid flooding the backend? In this case the loopback is actually quite useful. Currently the backend (debug window) builds up a long tail if you drag with the option "on user interaction"

Perhaps I have to add a timeout in case a message is lost

[dceejay]

the built in widgets use a timeout to rate limit the updates from things like the slider etc. But it always a tradeoff between sending too many and making any animation look smooth.

[Christian-Me]

Thank you for the information, I will try both ... The wait until confirmed might be too slow as a little queue in buffer should help in smooth animations The tail animation when the picker is released is funny but a little bit irritating (will try to avoid this with a on release flag to find out when it is ok to handle messages as real updates from somewhere else - somehow.