Periodically Send Message on NOVA using Python fails on 2nd attempt

I’m trying to construct a very simple IOT device to monitor and control a remote cabin. I have attempted to code a first program that will receive periodic data (hourly data) and I want to send that information to the Hologram cloud where I have a route defined to forward that to a local email address. I have a working python script that hourly sends the temperature data in the form of a topic/message of topic: cabin/hour message:{“time”: date and time string, “temp”: local temperature}. The code to receive this topic/message (attached below with credentials removed) will run the first time with a response code of “Message sent successfully” (and I receive the expected email with the data), then then next time the topic/message is sent (one hour later) I get a “Unknown response code” result and the message does not get sent to the Hologram cloud. Is there something that I am missing that I need to include in the code? I am using a NOVA SARA-R410M-02B with the latest developer python api.

-----python code --------
import time
import paho.mqtt.client as mqtt
from Hologram.HologramCloud import HologramCloud
import sys

credentials = {‘devicekey’: ‘myCredentialsRemoved’}
hologram = HologramCloud(dict(), network=‘cellular’)

Broker = ‘localhost’

when connecting to MQTT do this

def on_connect(node, userdata, flags, rc):
print("Connected with Result code "+str(rc)+’\n’)

def on_log(client, userdata, level, buf):
print("log: ", buf)

when receiving a mqtt message do this

def on_message(node, userdata, msg):
global hologram
message = str(msg.payload.decode(“utf-8”))
topic = str(msg.topic)
print("on message: “+ topic +”: "+message)
if topic == ‘cabin/furnace/state’:
response = hologram.sendMessage(message, topics=[topic])

if topic == 'cabin/hour':
     response = hologram.sendMessage(message, topics = [topic])
     print(hologram.getResultString(response) , ' Hourly Temperature ', message)

client = mqtt.Client()
client.on_connect = on_connect
client.on_log = on_log
client.on_message = on_message
client.connect(Broker, 1883, 60)

result =
if result == False:
print(“Failed to Connect to network”)

while True:

except KeyboardInterrupt as e:
print(‘closing socket …’)

if not


-----End python code -------

A followup…

I think the MQTT logging was somehow corrupting the Hologram messaging. I removed the link to the on_log from the MQTT client and my script has worked well since then.

A side note, I was also having trouble receiving cloud data messages. The SDK error while trying to convert bytes to string which Python 3 does not do implicitly. I modified the in /home/pi/src/hologram-python/Hologram, to convert the bytes to string. That modification allowed the messages to arrive.

A second update… I spoke too soon… The script above will fail at some indeterminate time (3hrs - 4+ days) with the communication between the modem and the RPi locked up. That requires a hard reboot (complete power down or unplugging the modem from the USB and plugging it in) to get the script running again.

I don’t know if anyone is listening (cares?), My last connection with this program lasted from after 8/30 3pm to between 9/3 3 and 4pm before getting unknown response code from the API. I noticed that the Hologram Dashboard for this device changed connection type from “Connected” to “Session without data” at about the same time. I don’t know if this is causal or just a result of the connection failing on the RPi end.

If the status changed on the dashboard it means we received a session end signal from the carrier. I am assuming you meant it changed from connected to ready. If you mean it was stuck in a zero byte session, indicated by a pink dot on our usage graph then that usually means the modem is in a bad state with the tower and a reboot is usually required. You should be able to reboot the modem doing AT+CFUN=15


The session goes from a “blue” (Connected) to a “Pink” state (Connected without Data). I cannot reset the modem with the AT command set as I cannot get the CLI or a terminal session to recognize the serial port… sudo hologram modem operator returns a “ERROR: Unable to detect a usable serial port” or if I try to connect directly using screen /dev/ttyUSB1(or USB0) there is no response to any AT commands (I have tried AT, ATI, ATE, AT+++)

Which network does your modem connect to? If it is AT&T, I would bet that it is the same u-blox issue I and others have been fighting for a while. I am currently testing the most recent u-blox firmware update that should fix this… I’ll let you know. No issues yet.

is the PPP session still running at this time? Even if it disconnected from the tower if the PPP process is still running on the pi it will tie up the serial line. The SDK has a bug in it thats fixed in the upcoming release where it doesn’t tear down the PPP session properly after a disconnect. If you are curious how to check in python if the PPP process is still running and terminate it you can check out how the script does it here:

Dom, I don’t believe that the ppp session is running. (I did a sudo ps -ax | grep ppp and it only showed itself with ppp. I think that is equivalent to the method you pointed me towards.) The modem lights are still indicating a connection (solid blue and flashing red).

hmm the R410 shouldn’t flash if its connected… The leds should be solid on when connected to an LTE tower, even when a ppp session is not active.

The red LED has either flashed or was off, it has never been on solidly. The blue LED (power?) is on solidly.

Hmm… If you go on the dashboard and look at the sessions table what RAT does it say for the session data?

Does it say LTE? not that its entirely related but im curious what network and RAT it was using

Looks like ATT and LTE (btw: what does RAT stand for?)

Just short hand for the type of radio access technology the modem is using. Some have like 2g/3g fallback like the BG96 but I don’t think the R410 does. Still was curious :slight_smile: this is probably related to the firmware issues that @zbelding pointed out

So that means I will have to wait for the next release of firmware to see if that fixes my issue. :neutral_face:

no the current firmware release (the one they released last week) supposedly fixes this issue. We just havent had time to roll it into the firmware updater script since we honestly didnt know about it until a few days ago.

Ok I will look for the notice when the updater is ready with the new release.

BTW: Thanks for looking at this issue.

It’s been about 6 weeks, when will the updated firmware release be rolled into the firmware updater?