Hi,
Good morning. I am using a Cron based timer (15min). But the flow is running in every 30min. Not able to understand why it is adding another 15min.
Subbu
Given that cron string, I would expect that to run every 15 minutes, too. Where does the second screenshot in your post come from?
And what is your reasoning for thinking it is only running every 15 minutes? Is it possible that somewhere inside that Loop Node you are hitting a condition that is throwing an error or otherwise stopping the flow from completing and reaching the Debug Node?
The screen shot is from the Dbeaver. Inside the loop I have a Losant API for Flow:Errors with a duration of 840,000ms. Are these both adding up? They shouldn’t right.
I went into your account and found the workflow in question and can confirm it is indeed executing every 15 minutes, as your cron string dictates.
840,000 milliseconds equates to 14 minutes. Workflow timing and error metrics are aggregated and reported approximately every 15 minutes. So it could be that errors you are expecting to be returned in your call are not there because not enough time has passed for them to be in the aggregated results yet, or perhaps there simply were no errors in the duration window you are providing.
I know you’ve been working on this use case for a few weeks and have posted several questions related to it. I’m still very unclear on what the goal is here as it seems you are trying to return all errors from a set of workflows, and then report them over our MQTT broker to a topic that is being subscribed to in an edge workflow.
Maybe if we can take a step back, forget about the “how” for a moment, and you can provide us the requirement to fulfill that has been given to you by your product owner, we can take a different, more manageable approach to solving this.
I am working on a diagnostic dashboard development by gathering information like workflow errors, device connection status, flow execution times for the all the devices and sending it to a local device for a single device thru MQTT and to cloud via Azure Event Hub for multiple devices. These dashboards serve as a successor to device onboarding to help us in troubleshooting connection issues after device is onboarded.
There are a couple issues with your approach of periodically polling stats and errors in the cloud and pushing them down to the devices …
- If a device is offline at the moment the message is published from the application workflow to the MQTT broker, the device will never get the message. This is especially problematic since the whole point is to display issues in a dashboard served from the device itself.
- Workflow errors are aggregated and return at most 25 occurrences in a response. They also lack precise timing data; we only tell you in the API response that an error occurred within a given 15-minute window.
So what if instead you flip this so that you catch the errors at the device level and report them up to the cloud in real time?
- Using a Workflow Error Trigger, you can deploy a workflow to your devices that catches all uncaught exceptions as they occur. (You can also catch other scenarios within your workflows using a Throw Error Node if you aren’t doing that already.)
- Coming off the Workflow Error Trigger, you can take two parallel actions …
- Log the error to a local database for use in your local dashboard - for example, using a SQL Node.
- Publish the error info up to the cloud using an MQTT Node. If the device happens to be offline when the node is invoked, the message will be queued and will publish once the device re-establishes a connection to the broker.
- In an application workflow, an MQTT Trigger can fire on publishes to the topic used in the MQTT Node in the edge workflow.
- Coming off of that trigger, you can take any number of actions - but in your case you mentioned Azure Event Hubs, so you could then forward that message straight to that service using an Azure Event Hubs Node.
What you’re missing here is the execution timing information, and that is not easily exposed down at the edge device. We do have the information there as we are publishing it up to the cloud on a regular basis; I will file a feature request about exposing that in the workflow environment.
One thing you could do is calculate that time, relatively accurately, in a node at the end of every workflow run. (This requires updating any deployed workflows and ensuring any new flows / updates also end with such a node.) It would be a simple Handlebars template, something like …
{{subtract (currentDateTime 'x') (formatDate time 'x')}}
Another possibility would be to have the device itself make the API request for timing data. You could make an Application API Token that is limited to just the Flow: Stats request. You can make that request from an Edge Workflow on a regular basis using a Timer Trigger; the ID of the device and the workflow, which you’d need to make the request, are both available in the payload. (I’ll also file a feature request to allow a device to return all flows / versions deployed to it from within an edge workflow.)
While the request would fail if the device lacked internet connection, that is no worse than what you are doing now.
If you do go down either of these routes, I recommend packaging the functionality up in an Edge Custom Node.
1 Like
Thanks. Will try this approach certainly. Also please let me know once those feature request are implemented.
so far, to validate current methodology, created following workflow - 1min timer triggered, to generate errors. This workflow is basically creating errors. So, there should be sufficient errors in that 15min window.
Hi,
Thanks. I implemented an edge workflow to push the data (jsonEncode time) for testing purposes, into cloud using MQTT and collecting it on the application side. When I rebooted the system, the system approximately takes 4 min to come online. During these times, the info is lost. Messages are not queued. is this because I am using timestamp as info/data?
Well, if the GEA is not running, your Timer Triggers aren’t going to queue. There is no process generating messages, or errors for that matter.
The GEA will queue MQTT messages to publish to the cloud when the agent is running but does not have an internet connection; it is not keeping track of the time difference from when the process was last running and queuing up Timer Triggers or any other processes that would have run in that time when it boots.
I missed that part. Thanks, a lot. I followed this (Connecting Azure IoT using MQTT)to create an MQTT integration. But its disconnected. How do I troubleshoot?
If you hover your mouse over the status in the top right corner, you’ll see the reason for the disconnection.
You can also configure the MQTT Trigger to fire on disconnections / failures to connect, which you could use to capture the error.
Thanks. Its authorization error.