Tips for decision matrix constructs.

Checking for more

Sometimes people need to check for other conditions then what the standard decision matrix in the firmware code is designed to handle. This occurs as its construct only allow for checks of originating node id, zone, and subzone. So the question is

If my node need to check some other bytes of the data for some match before I trigger an action, am I lost then?

Some would do there own decision matrix structure to solve this. But that is not a good solution as it means all tools that handle the decision matrix also need to be changed. A better solution is to use registers. For example

You have a need in your node to check that the values in byte 3 and 7 have certain values before you trigger an action.

Your action therefore becomes something like

Do X if data byte 3 is equal to register y1 and data byte 7 is greater than register y2

You can now still use standard tools to configure both the dm and needed registers.

If you need it you can do indexing by coding your action so parts of it is an index into registers to compare data with. For example us the low tree bits of the action be the index to use into register space (with a specified base).

The best thing with this solution is that it also works the same way with higher level data. For example if you have a node that send radiation measurements as floating point values and you want to do action X when the value is above a certain limit you do this the same way as above but now the value stored in the registers is the floating point value.

So the bottom line is. If you need more tests do them in the action. There are 255 actions available and that is plenty for most scenarios.

firmware/tips_for_decision_matrix_constructs.txt · Last modified: 2015/05/27 09:44 by akhe
[unknown button type]
Except where otherwise noted, content on this wiki is licensed under the following license: Public Domain
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki