I am working on a project for Easter. My kids have outgrown the traditional Easter Egg hunt so each year we devise a "hunt" that is getting increasingly complex. This year we have a stuffed bunny that contains a NodeMCU with a RFID reader inside, an Alexa Pod and a large 3000 mAh battery. The kids will find items that may have an RFID tag inside that they need to present to the bunny for their next clue.
The bunny reads the tag and sends an mqtt payload to NodeRed that decides what to do. Mostly say something over the Alexa Pod and sometimes open a lock or reveal other clues.
My question is, I plan to have some 55 tags in the game. Is there a limit how many outputs I can put into a Switch Node? Is there an easier way to program this?
Next, some of the tags may be used more than once. I plan to simply increment a flow variable for each tag as it is read. In most cases if the tag has already been read, I won't do anything, but on some I need to send a different message through the Alexa Pod.
I would use some sort of lookup table, something like an array of tag ids and whatever you need to identify the matching action. Then you just have to find the tag in the array to get the action. Possibly the data would be
[ {id: 12345, action: "text message or whatever is needed"}.
{id:...},
... ]
Possible you could setup the data in a CSV file and read that in at the start to give the tags and actions.
It won't be pretty as I only have a week to get all the tech pieces to work before we plan to do a "dress rehearsal".
In addition to the bunny, I built an egg-laying box that drops a plastic egg when the Arduino inside receives the correct mqtt payload. It has a second Arduino connected to a speaker to make squawking noise when the egg gets laid. Of course there's a chicken on top. (For last year's game I hacked a Simon game that sent an mqtt message when the green button was pressed six times. The player never figured out the hack and spent quite a bit of time playing the game and getting eggs). In this year's game, the bunny "reads" the RFID code inside various items; some of them will drop an egg.
There is also a box with an egg inside that opens on mqtt command. It has a NodeMCU and a battery that controls a servo that holds the cover closed. One of the items the bunny "reads" will open the box. If I can get it finished in time for the rehearsal, I plan to put an electromagnet in the attic that will hold a key to the ceiling below- until the bunny reads the RFID code to drop it.
That is wonderful!! I'm so impressed. I have a couple grandson's coming out to visit in July and I have to use these ideas (dashing off to Aliexpress to place yet another order)...
Not sure about a hard limit, but I've done flows that had switch nodes with way more than 55 outputs (can't remember how many, but I think it was up into the 160 range and was an utter nightmare of terrible design on my part.)
I'd argue against imposing an artificial limit. It's rare, but I've run across a couple old rs232 connected medical devices (ventilators) that are capable of outputting over 100 different data points of different types that need to be handled as their own animal (some are strings, some are int, some are float, and so on.) I'm talking gear that predates XML or JSON, so it's a pain to work with and I'm hesitant to cascade switch nodes using an "otherwise" at the end (though I'm not familiar enough with the behind-the-scenes stuff to know whether that would actually have a performance impact at all.)
I also know such devices, but even if there are 100 or more different datapoints, they do not have 100 different data types - so all the int's can be handled the same way, all the floats and so on.
And as mentioned before, one could send the msg containing the data to all "input handlers" and only the proper handler reacts.
Well, this happened. My flow was looking like a bowl of spaghetti.
Links helped clean it up a lot. (I sure wish we could give the links a visible label).
Also, cascading the switches with each having an "otherwise" output feeding the next switch node.
Well, that's embarrassing. I asked for this feature on the GIT a few months ago, but I am still running 0.19.5. I will upgrade after the Easter project because upgrades here almost always break something.
