Gammu Laravel Package

Product Decisions This Supports

• Channel expansion for SMS alerts on a budget. This package lets a Laravel app deliver notifications through gammu, i.e. a locally attached GSM modem/USB dongle rather than a cloud SMS aggregator. It informs the build-vs-buy decision for any "notify users who don't have smartphones/email" requirement.
• On-prem / air-gapped / low-connectivity deployments. Gammu (the underlying CLI) can operate without internet egress. This supports roadmap decisions for field ops, rural clinics, industrial sites, or regulated environments where routing message content through a third-party API is undesirable.
• Data residency and cost posture. Sending via owned SIM hardware keeps recipient phone numbers and message bodies inside your infrastructure, and replaces per-message aggregator fees with a SIM plan. Feeds pricing and vendor-risk discussions for high-volume alerting.
• Use cases worth validating cheaply: internal ops alerts (server down, batch job failed), appointment/OTP-adjacent notifications in low-bandwidth regions, two-way SMS trials, and disaster-recovery notification paths that don't depend on a cloud provider.
• Integration surface is small enough to de-risk. The package is a thin adapter over Laravel's NotificationChannel contract plus a Gammu CLI call. That means it mainly informs an architecture decision (Laravel Notifications as the abstraction for all outbound messaging, with pluggable transports) rather than a deep platform commitment.
• Not a roadmap commitment on its own. With 14 stars, zero dependents, and no release since December 2016, treat adoption as a spike/prototype input — evidence that the channel shape works — not as a dependency you plan a quarter around.

When to Consider This Package

Consider it when:

• You are already running Gammu or gammu-smsd for SMS and want Laravel's Notifier/Notification facade to be the single dispatch point for all channels (mail, database, SMS).
• You are on, or can tolerate, Laravel 5.3-era APIs — this predates the modern NotificationChannel ergonomics, PHP 8 typed properties, and Laravel 9+ conventions.
• Volume is low (tens to low hundreds per day), one-way, and best-effort delivery is acceptable.
• The effort is time-boxed (a day or two), and you are willing to fork and vendor the code into your own namespace rather than depend on Packagist.
• You need a proof of concept for a hardware-SMS transport before investing in a first-party channel.

Look elsewhere when:

• You need modern Laravel (8/9/10/11) or PHP 8+ compatibility — expect to rewrite the service provider and channel regardless.
• You need delivery receipts, retry/backoff semantics, two-way inbound handling, or idempotency; gammu-smsd supports these but this package does not surface them.
• Throughput matters: a single GSM modem is a serialized bottleneck (roughly seconds per message) and SIMs get throttled or rate-limited by carriers.
• Reliability matters: USB modems hang, SIMs lose registration, and there is no failover in the wrapper.
• You want vendor support, security patching, or an auditable maintenance trail — none exists here (last release 2016-12-19, unmaintained).
• A cloud aggregator is acceptable — mature channels (twilio, vonage, smsapi, etc.) will cost less in engineering time than maintaining modem hardware.

Default PM recommendation: do not add as a dependency. Use it as a reference implementation, then build a small in-house channel (typically 50–150 lines) around gammu-smsd-inject so you own queueing, logging, retries, and Laravel version currency.

How to Pitch It (Stakeholders)

For executives: There is a niche capability we can unlock cheaply — sending SMS from our own server through a £20 GSM modem instead of paying a cloud SMS provider per message, with message content and recipient numbers never leaving our infrastructure. A community package already sketches this integration with Laravel, but it was last updated in 2016 and has effectively no user base, so it is not something we should depend on in production. The recommendation is a short, low-cost spike: replicate the pattern in-house (roughly 1–2 engineering days) and validate it against one real alerting use case. If it works, we get a resilient, low-cost, data-resident notification path for ops alerts and low-connectivity users; if it doesn't, we've spent two days and learned that our SMS needs belong with a managed provider.

For engineering: Laravel's notification system already abstracts the transport, so the work is a thin channel that shells out to Gammu and maps responses to exceptions. Adopt the package's shape, not its code: fork the pattern, target our current Laravel and PHP versions, wrap the CLI call behind an interface so it's testable, and put queueing, retry, and delivery-receipt logging in our layer. Skip the abandoned dependency and its 5.3-era service provider entirely.