I think SMS sending is different between different firmware versions. When I send SMS with old and new FW to my mobile phone, both messages look like identical but when I send same message to our IoT device, that device doesn’t understand message I sent with new firmware.
Is there something different between fw versions? Some different SMS encoding? Some invisible characters within sent message? Something is changed because firmwares before new API work but firmwares after new API does not work.
The message I try to send is like “11:AB:98:FF:07:DE ED01” without quotes.
After looking through the changelogs, I can’t see any particular changes with the way SMS messages are being sent. What are you trying to do with the SMS messages you send in particular?
No invisible characters or such are being sent with the SMS messages, I can confirm this as I have a device with very old firmware, and a device with very new firmware, and both of their messages, at least to the eye, look identical.
We are sending commands (to reboot or do something else) to some IoT devices. Sending using our old RUTXR1 with firmware 7.12.3 and POST/GET method works.
But because “With the introduction of RutOS 7.14, the Mobile POST/GET and I/O POST/GET services will be removed from the firmware and will no longer be available in the package manager.” I understand that we can’t use that method to send SMS if we update to FW 7.14 or newer.
So we got new RUTXR1 with 7.17.1 firmware and I created an script that uses the new API to send SMS.
I sent same message with old device and new device but our IoT device does not recognize message sent with new one. I can see that message got received but something is different. And as I said earlier, if I send same message to my mobile phone, both messages look the same.
I think we tried to send message with API, gsmctl and browser GUI and messages sent from new device just don’t work. Message contents are basically “”, no special characters, only 0-9, A-Z, space and colon.
The receiving IoT device doesn’t have any sender filtering which could affect this.
We have several different IoT devices but the device I found this problem is a device that transmits alarms. I think it has nrf9160 as a modem if it matters. We have very limited possibilities to debug this problem “inside” that IoT device.
Could you provide examples of the SMS messages being sent via different device functionalities (WebUI, GSMCTL, API) and the output that you receive on your end-devices?
Oh, my message example previously was somehow removed by your platform. As I mentioned previously, messages are MAC-Address, space and four-character command, like “11:AB:98:FF:07:DE ED01” without quotes.
I tried to send same message using new and old device (both RUTXR1), only difference is device firmware version and modem firmware version, as I mentioned earlier. On older device, WebUI, gsmctl and old HTTP POST/GET -method works. Using newer device with newer firmwares, using WebUI, gsmctl or API, none of messages are recognized as commands in those IoT devices. I can’t see the exact message received at IoT device but I can see that if I send reboot message, messages sent with older device are accepted and device reboots but nothing happens when I send exactly same messages from newer device.
Some other IoT devices understand both messages, sent from older or newer device but those are IoT devices from different manufacturer.
As I mentioned earlier, if I send same messages to my mobile phone, messages look identical. But something is different, because some devices don’t understand those messages. Is there difference in character encoding, some metadata or hidden characters, BOM or something?
I checked firmware release notes and noticed some things that could affect this because of modifications in SMS functionality:
RUTX_R_00.07.16.1: increased SMS text length from 3 to 8 messages
RUTX_R_00.07.13: SMS Utilities: changed format of ADC and ACL status
This part is what caught my eye the most, could this signal a compatibility issue, possibly?
Still, regarding the output, I’d like to know/see what output the end-device (IoT device) sees, in other words, a screenshot of the received SMS to the IoT device.
I have no way to see what end-device sees, all I can see if device responds to the message. We have no debug interface to those devices. All I can see (via IoT SIM portal) that device receives a message. If I had been able to see the messages, I would have attached the differences to my answer.
We have sent hundreds of messages to those devices with older RUTXR1 and those messages all worked. So something has changed betveen firmware (or modem) versions. But because we want to update firmware to more current (because of security updates) and old HTTP POST/GET method is removed in newer firmwares we discovered this problem.
The R&D have requested 2 troubleshoot files - 1 from when the SMS messages work, and 1 from when the SMS messages do not work. To be able to send us the file, we have sent you a form to fill out, which you will receive in your e-mail inbox that you have registered your account with in the forums. In the Ticket ID field of the form, please enter the ID of this thread, which is 15490.
The client has resolved their issue. The problem was that the receiving device did not accept messages if the sender’s phone number was one digit longer than usual. So, a country code with a 9-digit phone number works, but a country code with a 10-digit phone number doesn’t.