# Beginner questions on IF expressions and wildcard usage in function node

**URL:** <https://discourse.nodered.org/t/beginner-questions-on-if-expressions-and-wildcard-usage-in-function-node/80999>\
**Category:** General\
**Created:** [3 September 2023 11:43 UTC](https://discourse.nodered.org/t/beginner-questions-on-if-expressions-and-wildcard-usage-in-function-node/80999 "2023-09-03T11:43:38Z")\
**Posts on this page:** 1\
**Showing post:** 43

<div class="post-metadata">

**Author:** ![AleXSR700](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/alexsr700/32/41161_2.png) [@AleXSR700](https://discourse.nodered.org/u/AleXSR700)\
**Post date:** [5 September 2023 10:49 UTC](https://discourse.nodered.org/t/beginner-questions-on-if-expressions-and-wildcard-usage-in-function-node/80999/43 "2023-09-05T10:49:57Z")

</div>

> [@jbudd](#):
>
> My first thought looking at that flow diagram was that you have an awful lot of function nodes.  
> On reflection, each of your functions is probably relatively simple, so no doubt more easily maintained than a single complex function.
> 
> I do wonder why you have no switch nodes to route messages along one wire or another based on the message properties, nor change nodes to adjust the message structure for your requirements.

I do have other flows where I use the "simpler" switch, change etc. nodes. But I have found that albeit being super simple in the beginning, they quickly become bottle necks.  
So I decided to try to do as much as possible with functions. This has the added benefit of being able to learn much more and perform more complex tasks in the future 🙂

> [@jbudd](#):
>
> It looks like your output may be multiple messages, each with a single item of data.  
> I wonder why you need this?

The debug nodes are actually not my real output. They are really just for debugging right now. The output will later be an mqtt out node.  
So in the current stage of my little project, I am separating the data for processing.  
This will be followed by a block of functions that will process the data.  
Once processed, the different streams will be re-joined to form one output message (per device... see more on that in my response to Colin)

> [@jbudd](#):
>
> No criticism intended here, just interested observations:

Perfectly valid points 🙂

> [@Colin](#):
>
> To concur with @jbudd's comments, it appears you are bringing all the data in from different devices under the same topic and then examining the data to work out what is in it. That is horribly inefficient. For example you will be checking all the properties of messages to see if they are ATC\*, when you know that they are actually from a different device type.

Maybe I need to elaborate a bit more.

Device types are different hardware types (usually linked to different manufacturers).  
So I have:

- Shelly 1PM, Shelly 2.5 and Shelly 3EM.
- Gosund SP1 and Gosund SP112.
- Refoss P11
- Xiaomi Mijia Thermometer & Hygrometer
- eq3 Thermostat (heating valve)  
Devices are then "one piece of hardware" no matter who the manufacturer. Entities are then e.g. power sensor, energy total sensor, power switch etc.

The first three device types are running with tasmota firmware. So they will all have the respective device\_id in the topic, e.g. "tele/tasmota\_12345678" which is based on the MAC of the devices.  
These run to the bottom flow because they are all power sensors and their messages are all very similar.  
So the first function checks if it is one of these device types. Since the topic contains the device id, I do not need to split into devices anymore. The second function then splits into the entities Energy Power, Energy Total and Energy Today.  
However, those with multiple outputs (e.g. Shelly 2.5 or Shelly 3EM) will need separate processing of these 3 outputs, hence then another function splitting into the entities Power[0] to Power[3].

The Xiaomi and eq3 are in fact bluetooth devices with their own firmware (whose behavior I cannot really influence). They are relayed through an ESP32 dev kit board running tasmota.  
So the data comes in via bluetooth to the ESP32 and the ESP32 then relays/publishes the data as MQTT messages via Wifi.  
Each Xiaomi device uses "ATC" + a unique ID based on MAC to identify itself to tasmota.

Tasmota does not use the same topic as it does for the Shelly/Gosund device types. This alternative topic is _ **not** _ device specific but device type specific. Meaning, all Xiaomi Mijia devices' data are published via one large message with just one topic (they may be split into multiple messages if there are more than 4 Xiaomi devices).

So I need the top flow to check the _message_ for "ATC" and not the topic.  
The same applies to the eq3 valves, which I have not implemented yet because they are not used in summer (and are essentially clone nodes of the ATC flow).

Maybe as an additional note:  
I could of course join different functions into one and have less processing steps. But right now this makes it easier to work out mistakes and to follow the processing.  
**IF** this leads to performance problems later, I will merge them into fewer but larger functions.  
Until then I think it is easier for you to support and me to learn if I keep each step in a separate node.

P.S.:  
Of course I am happy to share the final glow later. It is currently in a private github repo but once I have a more refined and more feature rich flow, I will happily share it with whoever is interested. 🙂

---

_[View the full topic](https://discourse.nodered.org/t/beginner-questions-on-if-expressions-and-wildcard-usage-in-function-node/80999)._