We use the FX30 with Octave and the Energiya IO cards as an edge capable IO device. Whenever one input turns on it sends a data post with every variable included. This makes discovering which input turned on inconvenient. What I want to do is have a second payload that is sent to a second “troubleshooting” stream that contains the input that was turned on. The problem is we do not want this second stream to be enabled all the time because it will drive up our already high message count. Is there a way to enable/disable this secondary stream? We could always comment the payload out once the device is set up and tested, but we would have to do this in eleven edge actions. Would deleting and recreating the stream when we need it work? I’m hoping there is a more elegant solution, but this might be the best option.
Hello Wilson,
I took a brief look at your solution. It is worth a meeting to discuss how you could streamline (cut down on the number of observations) by using one resource as input to an edge action, using the datahub to read all the other resources (as needed) in the same edge action and then decide what payload needs to be constructed to actually go to the cloud (is any payload at all) . This will drastically cut down on your message bill.
You can also cut down the number of edge actions by routing multiple observations, inputs or resources into one edge action
See Accessing Data from Other Resources
Working with Observations
If you are conducting sequential time based logic condition, this can be a bit trickier. Example would be to control systems at 0 seconds, 15 seconds, 2 hours, etc, based upon conditions at those time stamps. Still it would be useful to understand you solution requirements and using timers might help you to streamline as well.
But I digress…
To answer this particular question, I use a boolean virtual resource that can be set T/F from Octave via the UI or API (from your cloud) and that controls whether or not to send a particular “debug” payload. In your current solution, You would write one identical function in all your edge actions and one line of code to execute the function and place that in your edge actions. No such thing as a library of functions across edge actions, but we are working on that. You could make the debug setting :“smarter” by checking conditions on the device and using those conditions to set debug on/off. This just depends on your requirements.
I hope this helps.
Hello David,
Yes I realize that our solution looks very cluttered and could use some streamlining. We just went through a design change where we moved each payload to one central message because we realized that sending “partial” messages with only the data we needed was messing with our endpoint. If a variable isn’t included in the most previous message it shows as a “null” on our website. That’s unique to our situation, so I won’t clutter the forum post with more information about it.
I really like the idea that you proposed above about making a true/false value in memory and this can control the debug log. This is an elegant solution we can work with, and I will try to implement it soon. This will make our initial testing much easier. Whenever each alarm had its own message, it was easy to see which messages got sent, but now it is more inconvenient because we have to open the dropdown and search through our tag list for the right variable. I hope that explanation makes sense, but regardless we’re pleased with the solution suggested. Thanks!