Sending newline

Continuing the discussion from Is it possible to include '\n' in SMS-ovef-IP using the Embedded API?:

How do you create a newline char when using the (deprecated but not dead) “SMS-over-IP” embedded endpoint?

Solution provided by Reuben:
Ok so the docs apparently never reflected reality here. We’ve always taken a single newline on the SMS endpoint to end the connection.
We’re going to leave that in place, but now you can send the characters \n (not an actual newline) to create a newline in the message.
Let us know if that gives you any trouble.
We’ll update the docs with this information soon.

New question:
In my testing, this same solution seems to apply to sending newlines using the “Send a Message to the Hologram Cloud” embedded endpoint. Is that expected/known? I’m hoping that this embedded endpoint is a very highly-used part of the Hologram system… is that true? I have probably tried your patience over the months asking about the longevity of the deprecated but not dead “SMS-over-IP” embedded endpoint, so with significant effort I have switched to using this endpoint + Twilio for sending SMSs. I’m hoping that this will ensure that my hardware product will have a long lifespan.

I’m hoping you can calm my fear that the “Send a Message to the Hologram Cloud” embedded endpoint will be deprecated or go the same way as the SMS-over-IP embedded endpoint… Thanks!

I believe they use the same code to parse incoming messages and route them appropriately so that should be the case.

Generally speaking no, the embedded method is not used as often as other communication methods, I would hope for obvious reasons where piping to netcat would be less desirable than a program with more error handling and logging.

That being said its not going anywhere since that endpoint is the same one used by a lot of services including the SDK. The day goes away would be the day we would do a massive change in how we handle incoming traffic and would break most customers devices, which would be bad.

The SMS endpoint was deprecated due to the abusable nature of it. Carriers don’t like people sending spam SMS messages and while it was a useful tool for a few people there are other ways of doing the same thing, as you have discovered, that limits our liability.

Cool, that sounds good. But I’m surprised more people aren’t using the embedded stuff. I am using a SimCom SIM7000 chip with an Arduino Nano and it seems like this kind of deal would be a perfect use case for Hologram… yall even used to have a “Maker” plan. My little Nano is 96% full of C code, so I’m fighting for space, and even using the API probably wouldn’t have worked, so thank goodness for the embedded endpoints. My project might be dead in the water otherwise, or I’d have to remove some features.

It seems like Arduino is way more IoT friendly vs Pi based on price, power consumption, etc. Pi isn’t really a “Thing” IMO, it’s just a small computer.

Thanks again.

You would think but most established companies usually use either a prefabbed module or make their own. The amount of makers has never really seen a marked increase, I think part of it is that as a hobby paying upkeep for a cellular device is less desirable than using alternatives that are free or they already pay for as part of their day to day lives (wifi or BLE)

You would also be surprised as to the amount of people using linux and usb modems vs RTOS like arduinos. The nova sold better and has been used in more products than the dash (not sure if you remember that hardware). I believe people want the ease that comes with just plugging in a usb stick or a program that can easily be tested and run on a machine with little setup. We use the pi for a lot of things because its so easy to just stand up a program and have it be flexible, can ssh into it and modify configs etc. that are just not as easy on RTOS devices.

That certainly would have been a lot easier solution, but would be too expensive and power consumptive for me. I’m making a kill switch/tracker aimed specifically at the VW community. Even with relatively low power consumption (tested higher than claimed by the components) it will kill a car battery in a couple weeks.

I looked at your website and it’s very impressive. Going to look into openFrameworks now!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.