Hi @kenneth_oslo​ , did you solve the problem? I'm in the same situation right now.

Hi @Jacob Million​. Our project has now ended, but no, we didn't find any other workaround except having two different scheduled jobs. One checking the log every 20 mins, and the other hourly (could indeed have been more often) getting data from the data providers (brokers) API. But in fact, this proved to be quite a good solution after all, as the broker sometimes had lag or other issues on their side.

The "log checking job" was simply checking if any activity last 30 mins, and if not, sending email warning. The job fetching data from the API, was comparing the received data with the data stored in our database from the MQTT Stream. If the number of features with mismatching data was 5 or more, it sent an email warning. Note that if you have a decent amount of sensor activity, it should be higher than 0, because of some ms latency, so you would then expect a few features showing mismatching data (API call vs MQTT). The number of features with mismatching data accepted, should be tweaked until it seems right. When receiving email warnings, we had to manually check what could be wrong. Sometimes the MQTT Stream just needed a restart, and sometimes our data supplier had to fix a problem on their side (broker). In general, these things didn't happen more than perhaps 7-8 times total during a 12 month period after we setup the MQTT job as a Stream on FME Server, except sometimes during holidays when sensor activity was abnormally low during night time (false warnings).

Oh, one more thing: Depending on the QoS (Quality of Service) set up on the MQTT Stream (and by the broker), you might want to regularly run API calls anyways, and use the fetched data to update the features in your database that's has failed to update via MQTT.

GL!