The problem is that fixed part of most plans’ pricing make the cost prohibitive, not the pay-as-you-go component (eg the cost of a sim and phone number).
We were able to use a LoRa-like layer to forward to a base station that then uses a VoIP provider to do the brunt of the communication work.
I think I failed to convey my point clearly. My point is that if you need a separate sim per IoT device, the (possibly monthly) cost of a sim and number will greatly exceed the cost of messages sent.
That makes sense. The provider incurs an ongoing (trivial to them in bulk) cost for leasing you the number so they can’t let them go stale - although three months is definitely more than lining their pockets. My VoIP provider charges a fixed 99c/month for each unique phone number. 15 € for three months is cheap for personal purposes when you have just a few in the field but isn’t sustainable for large scale deployment. I continue to be impressed by what can be accomplished in the 915 MHz ISM band; it’s not LoRaWan proper but you can achieve non-line-of-sight communication over a hundred and fifty miles (at obviously incredibly slow bitrates) with some signal conditioning magic. It would be amazing to spread a network of these around the world to enable constant low-bitrate communication without a base rate for pure pay-as-you-go options.
True, but that's using SMS for telemetry (totally valid for use cases where power or connectivity are challenges) or remote control, not brokering SMS between another medium; this use case is forwarding SMS messages to Telegram. Maybe if you had a SIM for a geography that wasn't supported by a VoIP provider for programmatic access?
Think of this as much about being a learning exercise as anything else. The project doesn't need to stand on it's own - the creator gets to learn something about both sides.
It's like seeing that M.2 is PCI-E, and wondering if they can plug a regular video card into it. :)
Although for this project, I can construct systems in my head where this would be useful, centered around non-US mobile plans which are "calling party pays", with free on-net SMS. The US is "bill and keep", which makes sending SMS off-net largely the same as on-net from the carrier's point of view.
In "calling party pays", having a device on the same network as the controlled device is about avoiding per-SMS charges.
I imagine they mean this specific use case where you need ip connectivity to Telegram anyway. If it were bridging to something local, it would make more sense.
We were able to use a LoRa-like layer to forward to a base station that then uses a VoIP provider to do the brunt of the communication work.