When the Flexy is sending the data to the data mailbox is there a specific amount of time that has to pass between data syncs? We have some script that will call a dmsync if an alarm has changed status. The dmsync will fail with error 503 if there was a recent dmsync from the Flexy unit. Seems like we have to wait at least one minute and 15 seconds between dmsync calls.
There is no limit hard limit set to calling DMsync, however if you have a previous call still being processes this can cause a 503 error. The exact time between being able to make another sync can vary depending on the amount of data you are syncing and the load on the server. Generally we do not recommend a sync faster then one minute the data mailbox is not intended to be a live data system.
We have the Flexy set to sync to the mailbox on alarm and on a time of 15 minutes. If there is an alarm the Flexy will sync to the mailbox. If there is another tag that goes into alarm say 30 seconds after the first one the Flexy will try to sync again as it is supposed to sync on alarm. This will cause the 503 error as the sync call is too close to the previous one. So the second alarm will be missed until the next scheduled sync. Also if a tag goes into alarm and a sync happens close to the scheduled sync time the scheduled sync will error and will be missed until the next scheduled time.
That sounds right if there is already a sync being processes the next will fail. This is only pushing to the data mailbox so you are only going to miss data when you pull data from the mailbox. The data mailbox is not intended to be a live system, are you using it to watch alarms?
We are not using it to watch for alarms. We have a basic script that checks for alarms on a Flexy and then posts to a queue on Azure to alert that an alarm has occurred.
Just trying to understand why we are getting 503 errors in the log files when trying to do a simple data sync to the mailbox. Seems like this should be something that would be communicated and corrected.
How can we check for the 503 error so we can handle it wen it occurs?
Are you using the data mailbox or are you syncing to the azure server? If you are syncing to the azure server that would what is returning the response. The reason for the 503 is most likely the same, where the previous request is still being processed.
When you run the dmsync the response should be in the scheduled queue. You should be able to get the calls ID then check for an the response. If needed I can look into the specifics next week on how this would be done with the DMsync call. I believe it should be similar to the RESPONSEHTTPX example in the user manual.
We are using the data mailbox. The Azure part is just a notification that kicks off a different work flow.
Are there any examples of code for posting to Azure instead of using the data mailbox for the data transfer?
We have a post regarding getting data from the datamailbox with Azure. Can I use Azure Functions (serverless functions) to sync data from Talk2m to Microsoft Azure?
To go directly from the eWon to Azure you would need to perform a put request with basic scripting. Here is a thread that discusses that process. Azure IOT cloud
Can you post an example where we can check the status of a called dmsync.
After further investigating this it does not look like we can get the transaction ID to check the status and the method I was thinking of will not work.
What I would suggest is changing your implementation to not push to the data mailbox so often. As stated previously the data mailbox is not intended to be a live data access and is working as expected. What are you trying to gain by syncing on alarms, it seems like you are posting to Azure to alert you an alarm is occurred.
One option I can think of would be to start a timer that toggles a bit that would delay the next DMsync call.
We have changed from relying on the datamail box sync on alarm to having the Flexy post a message to an Azure queue on alarm. This will then to kickoff a work flow in Azure to get the information from the Flexy unit.