Include SIM card information in system:ping events

[elegance]

Feature request

Please include SIM card information in the system:ping event payload.

Motivation

External systems need to know which SIM cards are currently available on each device, so they can more accurately choose the target device and SIM card when scheduling SMS sending jobs.

Requested behavior

• Add SIM card details to the system:ping event, such as the available SIM slots/cards and any identifiers that are already safely exposed by the app.
• Emit an event immediately when a SIM card is inserted or removed, instead of waiting for the next regular ping.
• This would allow external systems to keep their device-to-SIM mapping up to date and make better routing decisions for outgoing SMS messages.

[capcom6]

Hello!

Thank you for your proposal.

SIM card information has been added to the latest pre-release version of the app in response to the GET /devices request.

Why does the SIM card list change dynamically, requiring to periodically update it via system:ping? I assume the SIM card list is static and changes very rarely. Could you please provide more details about your setup? Or perhaps accessing the SIM card list via GET /devices would be sufficient?

Best Regards,

[elegance]

Hello!

Thank you for the quick response and for adding SIM card information to the latest pre-release version.

Yes, I also noticed that the SIM card list is now available via GET /devices. For self-hosted/private server deployments, I assume the server side may not be updated yet, right?

I agree that SIM cards are usually static and do not change frequently. In my setup, however, there may be dozens of devices now, and possibly more later. Each device may have two SIM cards. The main reasons I was hoping to have this information in system:ping or related events are:

1. When a device initially comes online and sends a ping, my external system can immediately receive the device and SIM card mapping without needing an additional polling step.
2. In our previous hardware setup, devices occasionally had issues, and we had to remove a SIM card and insert it into another device for testing or recovery. If SIM insert/remove actions can trigger an event, the external system can update the mapping more promptly, without depending on the polling interval for GET /devices.

So GET /device is definitely useful, but having event-based updates would make synchronization more immediate and easier to manage at scale.

Best regards!

A better approach might be to add dedicated event types:

• cards:change: Triggered when a SIM card is inserted or removed.
• device:offline: Triggered when the device is manually taken offline. Currently, the external system can only detect this after the heartbeat times out.
• device:online: Triggered when the device comes online, including reporting the current SIM card information.

[elegance]

I also observed another behavior and would like to ask about it:

When a device has two SIM cards, SMS sending still appears to be serialized between them. Even if I specify the SIM slot when calling the API, messages for the other SIM card only start sending after the current SIM card has finished.

Would it be possible to make sending parallel across different SIM cards? I am not sure whether this is limited by Android/the phone hardware itself. Also, could parallel sending cause any confusion or mismatch in the sent / delivered broadcast events?

[capcom6]

For self-hosted/private server deployments, I assume the server side may not be updated yet, right?

Yes, the pull request hasn't been merged yet, but the binaries and Docker image are available here.

Regarding the proposed events:

• cards:change - This would require caching SIM card information in the app, which I consider unnecessary complexity.
• device:offline - This won't work as intended on the device. For example, if the device loses internet connection, it won't be able to send this event. Therefore, for most users, it will appear as an unreliable event.
• device:online - There are many situations where a device changes its state from offline to online, and sometimes they are difficult to track. Also, "online" for a device doesn't always correspond to "online" for the webhook receiver. For example, a device may have a Wi-Fi connection, but for some reason, it can't reach the webhook receiver. Therefore, the device itself is online, but from the webhook receiver's perspective, it isn't.

I can propose an app:started event, which is triggered when an app is launched via a home screen button or by the system in response to some other event. It will be sent simultaneously with a device registration request to a cloud/private server (if enabled). The registration request already contains SIM card information (in pre-release version), so it will be easy to send the same information via a webhook.

Would it be possible to make sending parallel across different SIM cards?

As far as I know, most Android phones only have one radio for multiple SIM cards. This keeps devices cheaper. Therefore, only one SIM card can be active at a time. This will only increase sending rates on devices with multiple radios, such as premium phones or specialized devices. Do you have any devices with multiple radios?

Regarding including SIM card information in the system:ping payload, I've added it to the project roadmap.

Thanks!

[elegance]

Thank you very much for the detailed reply and explanations.
My setup only uses multiple regular Android phones, not specialized devices with multiple radios.
Thanks again for adding SIM card information to the roadmap and for considering the use case!