No analysis could be performed in your detector model. No error message available. Please contact support.

Thanks for response.

Later it was possible again to publish the changes. Some time later it was not. But I wasn´t able to send an email via SNS if there are no incoming messages on a topic.

It seems, that I am not fully understand the mechanism of iot-events service.

My iot-devices send every minute a mqtt-message to a topic like "topic_part_1/device_name/data" I´ve a rule for the topic "topic_part_1/+/data" where I get write a dynamodb entry for each message. For the entry I generate a timestamp and extract the device_name from the topic and take the whole payload.

If a device stops to send data, I need an Alert.

There are no planned disconnections. For my understanding the livecycle-events are not the right way, because I never send a stop command. With the LWT I can`t send an Alert or can I?

Best regards

Hi Robin.

Am I seriously going to have to pay support now? Is this some kind of paywall?

No and no.

Or are there problems right now and I have to wait for it to work again at some point?

Possibly. Is it still occuring? If so, can you please elaborate on your steps so I can replicate?

Background: I want to determine if the IoT devices are still transmitting and send an email notification if not. I have been looking at different ways to implement this. So far, the solution with IoT events seemed to be the best choice, but I'm willing to be proven wrong.

Are these MQTT devices? Depending on what exactly you would mean by "still transmitting", you might instead consider to rely on MQTT keep alive and/or Last Will and Testament (LWT) mechanisms. MQTT client devices will send "keep alive" (PINGREQ) messages at regular intervals. If AWS IoT Core stops receiving PINGREQ, the client will be disconnected. You can use life cycle events to publish an MQTT message when disconnection occurs: https://docs.aws.amazon.com/iot/latest/developerguide/life-cycle-events.html#connect-disconnect. In this case, the reason would be MQTT_KEEP_ALIVE_TIMEOUT. You can then have an AWS IoT Core rule that reacts to disconnection messages published on this topic. Please take care to read the "Handling client disconnections" section.

If you're trying to catch a situation where your device maintains its MQTT connection, but would stop sending a particular message, then using IoT events is one valid approach.

So far I'm working with wildcard topics and it would be nice if I could keep that so I don't have to create a separate rule for each device. Is there a best practice there and am I on the right track, or am I making things unnecessarily difficult for myself?

Per best practices, your MQTT topics should include the thing name. It would be a normal approach to then use a + wildcard in the rule, on the thing name. That way a single rule would match for every device/thing.