Helpful criticism requested

General
42

Ok but how to designate it as a tag and not as a field?
RIght now I'm adding a tag named "BATCH" with a value of 'idle' and I can filter grafana using the tag in the WHERE field.

var payload = msg.payload;
var topic = msg.topic; 

switch (topic){
    case 'tick':
        context.set('time_tick', payload);
        //node.status({fill:"red",shape:"dot",text:msg.topic});
        if (context.get('enable') === true){
            msg.payload=[{
                  AMBIENT:context.get('ambient')||0,
               BREWBOX:context.get('brewbox')||0,
            BREWBUCKET:context.get('brewbucket')||0,
              SETPOINT:context.get('setpoint')||0,
                  HEAT:context.get('heat')||0,
                  COOL:context.get('cool')||0},{
                  BATCH:'idle'
            }]
        msg.topic = 'status_tick';
        return msg;
        }
        break;
    case 'enable':
        node.status({fill:"red",shape:"dot",text:topic +':' + payload});
        context.set('enable', payload);
        break;
    case 'ambient':
        //node.status({fill:"red",shape:"dot",text:msg.topic});
        context.set('ambient',payload);
        break;
    case 'brewbox':
        //node.status({fill:"red",shape:"dot",text:msg.topic});
        context.set('brewbox',payload);
        break;
    case 'brewbucket':
        //node.status({fill:"red",shape:"dot",text:msg.topic});
        context.set('brewbucket',payload);
        break;
    case 'setpoint':
        //node.status({fill:"red",shape:"dot",text:msg.topic});
        context.set('setpoint',payload);
        break;
    case 'heat':
        //node.status({fill:"red",shape:"dot",text:msg.topic});
        context.set('heat',payload);
        break;
    case 'cool':
        //node.status({fill:"red",shape:"dot",text:msg.topic});
        context.set('cool',payload);
        break;
    case 'end':
        context.set('enable', false);
        msg.topic = 'status_tick';
        return msg;
}

The magic happens in the case 'tick' switch.
This is a trail setup which will change when I'm satisfied it's going to be useful.
I'll ad a case 'tag' to make the 'BATCH' changeable from the UI.

43

Avoiding functions, preferring built in nodes is a good practice in NodeRed. Functions imply a context change in the core. This normally I'd not a problem because we normally use fast computers, but it slows processing down.

Sometimes it is easier (and fun) writing a function, but I'm most cases it can be solved using nodes.

Have a look to NodeRed courses in Coursera. You will discover how useful internal nodes are.

44

If performance is your goal then yes I agree. However there are many situations where it is not critical (typically things with an update rate less than 10 times a second) and the educational aspects of solving the problem in a contained environment outweigh the overheads. Of course people may then also discover the pitfalls and edge cases that (hopefully) the core nodes have already handled for them, but that is part of the learning.

45

The point of my post was to explore "best practice" in node-red and your reply is exactly on point.
Thanks, also for the coursera pointer. :slight_smile:

46

Your point about learning by writing functions is good advice too. Since I'm new to js it's a good learning tool and with the in context error checking by the editor I can try out ideas without disturbing my flows until i have all grammatical errors fixed. Logical errors is another animal. :wink:

1 Like