Waiting for a delta SP - Best Practice

Industrial
1

I'm looking for some guidance; best practice sort of thing.

My application will be reading a changing analog value, and will need to make some decision (state change) when the change reaches some set-point.

I'm using the awesome smxstate, so I'm partial to something folds nicely into that framework.

My first thought is to have a dedicated flow update a global context value using a interval trigger, and then in my smxstate flow, have an activity that calculates the latest delta and update some other context.

If that all seems like the right direction, then great. If there's some more formal Node-REDish way to do it, I'd love to hear about it.

Cheers!

2

It isn't a formal node-red way, but the principle of node-red is to pass information by messages. Unless there is a good reason to use context it is better to pass the information down the wires.

3

Understood, but when dealing with history (as is the case when making a delta calculation), is there some way to handle that "down the wires", as you say? Or isn't context the Node-RED way to deal with history?

4

Can you give a bit more detail on exactly what you want to do? With example data and the sequence of what happens?

5

Here are a few possibly helpful thoughts. Data flow languages like Node-RED often struggle a bit with tasks that require memory of previous events, so there is no perfect solution. There are several contributed state machine nodes in addition to smxstate, but they have (at least for me) a learning curve to program and can be overkill for simple problems. Using a context variable in a function or change node is often good enough. The "Node-RED way" is generally to limit the scope of context variables as much as possible: use node rather than flow rather than global context. Finally, there are core nodes that offer small scraps of special-purpose memory. It your case, it might be worth looking at the filter (formerly rbe) node. It can pass only messages where some property has changed by a specified amount or percentage, and so might help to detect the changes you want.

1 Like
6

I think the @drmibell reply is what I was looking for.

But think of it like this: I want to control a discrete output based on some change in an analog input.

So: output = analog_change < change_setpoint

where analog_change = analag_current - analog_startval and change_setpoint is given.

7

What do you mean by startval? The value when node-red is started? The previous sample?
How is the change_setpoint given? A fixed value? From dashboard input? Something else.

8

startval is some previous value.

setpoint is given through some message before startval is set.

9

You can use a Join node to get all the values into one message (startval, setpoint and current value) then a simple bit of javascript can compare them and determine what to output. Make sure the input messages have different topic values and set the join node to manual mode generating an key/value object. Set it to output after three message types and after every subsequent message.
Feed that into a function node which ignores any messages where the topic is not the current value topic (which means a new current value has just been received, and if it is the right topic then compare the values and output the appropriate message.

Build the above flow node by node and check each bit works as expected.

See this article in the cookbook for an example of how to join messages into one object.

1 Like
10

Running on my Pi, I still seem to have the rbe node, and it would be a lot more useful if the deadband amount could be set dynamically from the input message.

Maybe the filter node can do this? Or maybe rbe can as well but it's not documented?

11

The filter node is just the rbe node renamed, as the term rbe had caused confusion.

12

Maybe node-red-contrib-hysteresis would be useful to you.

13

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.