I previously had a Nova 2G/3G modem plugged in to a raspi which was run off of battery and solar power. The system worked great receiving cloud and SMS messages from the dashboard and SMS messages from my cell phone. The system replies by sending messages to the dashboard which are then routed to the correct cell phone based on message topics. Everything was working as I wanted it to be but the system was draining the battery faster than the solar panel I was using could charge it so I wanted to try the nova-m with LTE Cat-M and NB-IoT which is supposed to be more energy efficient. Using the LTE-M modem however I am not able to receive SMS messages.
I am in the United States and both the 2G/3G modem and the LTE-M/NB-IoT modem are connecting to AT&T.
Upon receiving the nova-M I registered a new SIM card plugged it into the modem, and then switched the new modem into my system.
Upon booting up the system I received a “Setup and running” message on my cell phone from the system and the SIM reported LTE connectivity on the dashboard. When I tried to send messages to the system from my phone though I received no response.
When I look on the dash I see that the dashboard is aware of the message I send from my phone, and even logs a response message from the SIM saying “SMS delivered,” the print statements inside the part of my code that receives messages never print though.
To receive messages I subscribe to “sms.received” events and “message.received” events and call an appropriate function whenever such an event occurs. Based on the print statements and logged messages in my code neither of these events are ever being triggered by the SMS messages I send.
When I try to send a message from the dashboard using cloud data however, the message is received successfully and a response message is sent and received successfully. The problem seems to only occur for SMS messages.
Should I try to intercept SMS messages on the dashboard and send them on as cloud messages or is there a solution to my problem that will allow me to receive SMS messages on the Nova-M over LTE-M.
Hi; I have a similar problem. Have you tried receiving the msg again a few hrs later? My modem (u410) can send SMS to my android phone and I’ll get the msg in reasonable time but if I send a msg to the u410 the latency can be hrs. No one so far has been able to help with this problem. Also, no one has told me how to clear the cache on the cloud. When I finally receive the msg, all other msgs which I have sent come in too.
So far I haven’t found this system very useful. Anyone have any answers?
Upon startup my program loops through the cache of received messages and prints them out. So far using the 410 I have not received any messages either by having a message trigger my subscription to the message.received event or by checking the cache on startup. Typically my program runs for 3-5 hours while I’m at work and sometimes I’ll leave it running overnight. It’s possible that I’m experiencing very high latency but I hope not because that would be an unusable amount of latency.
Not a very helpful answer but I have found SMS on Cat-M1 / SARA-R410M very unreliable and have abandoned it in my application which is unfortunate as its one of the only ways to “push” to these modems and a better method of sending secure commands than over the internet.
Have you abandoned the Cat-M1 / SARA-R410M entirely or have you found another way to communicate with it?
I’ve been playing around with using the dash to catch SMS messages intended for the Nova-M and then using the advanced webhook builder to forward them on to the Nova-M as a POST request.
I’ve had good luck sending messages to the Nova-M using a POST request from outside the dash but for some reason when I try to do it using the Advanced Webhook Builder on the dash I get the response
{“success”:false,“error”:“This user-agent is not allowed”}.
Posting to the Nova will be difficult as listening ports will be closed by the carrier after a period of inactivity (something like 10-30 minutes). So you will need to have a heartbeat to keep the channel open which to me wasted too much data.
I had to fallback to having my IoT devices poll a server for updates / commands. I don’t use Holograms cloud and have my own cloud server / protocol / etc. This gives considerable latency (whatever your polling frequency is) which is acceptable for my application but may not be for you.
EDIT: I should add the latency of polling a webserver for data can be high but it is also bound and controllable by me vs unknown and unpredictable with my experience with SMS. I have had some text messages go through but its a rarity and I spent a long time on multiple configurations of the SMS stack on the modem as well as trying out different carriers (Verizon and AT&T).
Hello everyone, I know it’s been a while since someone last posted here, and you may have gotten your question figured out. However, for those of you who are still finding this thread, and are wondering the same thing that started the thread. I will attempt to answer your questions from my experience with the R410/R412.
It turns out that your experience with SMS is a well documented issue, and it has to do with the MNO network that your modem might be riding on (NOT a hologram issue). More to the point, it has to do with what network gear the tower you are talking to, and what version of the standard it has implemented. I know this sounds ominous, and if you don’t do something about it, it will likely be a BIG problem as you move forward.
Fortunately, there is an answer, and that’s to set up a listening socket on UDP. It’s actually much lower cost overall, and provides a layer of security to your device, since it will be tucked nicely behind the hologram API, versus open for for everyone to exploit.
The procedure to test things out goes as follows, using a terminal interface…
Once connected to the network , set up an IP connection ( you probably do this already)
AT+CGDCONT=1,“IP”,“hologram”
Activate the profile (likely do this too)
AT+CGACT=1,1
Create a UDP socket (might be new to you), and it will return the socket number created. We will assume it returned “0”.
AT+USOCR=17
Listen on the socket created. it will return “OK” of you are in business.
AT+USOLI=0,4010
Go to your hologram dashboard and open the messaging console for the device you just set up, and select “cloud data” as the method versus “SMS”
Don’t forget to set the port (4010), and UDP as the method.
Type in your message and click send.
Eventually you should receive a ++UUSORF message
Send AT+USORF=0,1024 to the modem. This says get up to 1K bytes from socket 0.
The reply should tell you what IP address the data came from, and how many bytes are in the message, and then the message itself.
