I should point out that I am printing just about every response from the device now for diagnostics. so the responses might look different than you expect.
Looking into it this morning.
If the http address of the route proxy configured in Notehub is not returning JSON, then you will see this error message.
That is, if you set the address to āgoogle.comā or something similar. Please confirm the route in the Notehub project is pointing to an web address that will return JSON.
The program on the other endpoint of that IP address is the fileServerApp.py program from last week. I configured it the best I could, but im sure I did something wrong.
I just updated the route definition in your Notehub project to be appended with ā/downloadā
which was the configuration for the example web server I sent you.
Testing now
So Close.
I was running on a copy of our actual file and got this after a while.
'total_chunks': 246}, 'result': 200}
Requesting chunk 186 of 246
Step 2: {'body': {'chunk_num': 186, 'crc32': 2752505538, 'payload': 'b250PSgnSGVsdmV0aWNhIDI0Jyksa2V5PSdTdWJtaXQnKSwgc2cuQnV0dG9uKCcwJyxzaXplPSg0LDApLGZvbnQ9KCdIZWx2ZXRpY2EgMjQnKSksIHNnLkJ1dHRvbignQ2xyJyxzaXplPSg0LDApLGZvbnQ9KCdIZWx2ZXRpY2EgMjQnKSxrZXk9J0NsZWFyJyldLAogICAgICAgICAgICAgIFtzZy5UZXh0KHNpemU9KDE1LCAxKSwgZm9udD0oJ0hlbHZldGljYScsIDE4KSwgdGV4dF9jb2xvcj0ncmVkJywga2V5PSdvdXQnKV1dCgogICAgd2luZA==', 'total_chunks': 246}, 'result': 200}
Requesting chunk 187 of 246
Step 2: {'err': 'cannot allocate 2668 bytes {memory}'}
Step 2: {'err': 'cannot allocate 2668 bytes {memory}'}
Step 2: {'err': 'cannot allocate 2668 bytes {memory}'}
Step 2: {'err': 'cannot allocate 2668 bytes {memory}'}
Step 2: {'err': 'cannot allocate 2668 bytes {memory}'}
Step 2: {'err': 'cannot allocate 2668 by
Up until then, it was working great! The file in question is 61,407 bytes
Checking on this now
Iām able to reproduce. Let me see what we can do
ok.
from what I saw on the server:
35.172.219.169 - - [14/Jun/2021 18:49:10] "GET /download?file=test.py&chunk=157 HTTP/1.1" 200 -./../assets/test.py
35.172.219.169 - - [14/Jun/2021 18:49:10] "GET /download?file=test.py&chunk=158 HTTP/1.1" 200 -./../assets/test.py
35.172.219.169 - - [14/Jun/2021 18:49:13] "GET /download?file=test.py&chunk=159 HTTP/1.1" 200 -./../assets/test.py
35.172.219.169 - - [14/Jun/2021 18:49:13] "GET /download?file=test.py&chunk=160 HTTP/1.1" 200 -./../assets/test.py
35.172.219.169 - - [14/Jun/2021 18:49:14] "GET /download?file=test.py&chunk=161 HTTP/1.1" 200 -/../assets/test.py
35.172.219.169 - - [14/Jun/2021 18:49:15] "GET /download?file=test.py&chunk=1 HTTP/1.1" 200 -./../assets/test.py
35.172.219.169 - - [14/Jun/2021 18:49:15] "GET /download?file=test.py&chunk=163 HTTP/1.1" 200 -./../assets/test.py
35.172.219.169 - - [14/Jun/2021 18:49:16] "GET /download?file=test.py&chunk=164 HTTP/1.1" 200
After Chunk 161, it momentarily went back to 1 and then back to 163.
There does appear to be a memory leak in the web.get request.
Our development team is trying to fix it now, but Iām not sure weāll be able to get you an update before tomorrow morning.
I would say for now, a Notecard restart after a web request (or several web requests) should clear it out. Not ideal, but will get you moving forward.
{"req":"card.restart"}
Once the Notecard comes back up, you can continue to issue requests. In general, this isnāt going to lose data. Though it will result in a new connection to the cell network.
I realize this isnāt a fantastic workaround. Given the time constraints, I donāt think we can get you a firmware update in time.
@gwolff Thanks for all your help last week. I have moved forward and when I designate a file, it sends, receives, and translates correctly. I even added a progress bar to the code.
Now, Iām having trouble with the notifying.
How can I send you a zipped file_notifier.py and get_update.py? I would drop them in here but they have valid productIDs and sessionIDs and I wanted to leave them in to illustrate that that part is working properly.
It seems to arm the ATTN pin and recognizes that ATTN was fired, but I get the following from printing the req and rsp from that transaction:
Connecting to Notecard...
Configuring Product: com.xxxxxxx.yyyyyy:zzzzzzz..
Configuring ATTN...
ATTN Fired, checking inbound message...
{'req': 'note.get', 'file': 'file-update.qi', 'delete': True}
{'err': 'no notes available in queue {note-noexist}'}
Rearming ATTN...
The dashboard shows:
file-update.qi {"name":"test3.py","size":61407}
So I know the note is there and it gets triggered, but somehow its not seeing something correctly.
Thanks
I can take a look at this, but I may not get to it before tomorrow.
Itās possible the ATTN pin is firing for a reason other than the āfile-update.qiā having a new Note added from the cloud.
The error message you are seeing is expected if no new Notes are available in the Notefile.
If I remember correctly, the ATTN pin in the example application may also be triggered on a timeout (though I would need to double check on that)
After the ATTN pin is triggered, I recommend issuing a
{āreqā:ācard.attnā}
request. The response will contain information about why the ATTN was triggered. If it was because of a new Note in āfile-update.qiā, then that will be listed in the response to the ācard.attnā request above.
How do I send you a zip of my current files?
Hi Todd,
You can send me a private message on the forum and attach a ZIP. Or you can email it to support@blues.com.
Let me know if you have any issues.
Cheers!
Greg,
I switched out
from gpiozero import InputDevice
for
import RPi.GPIO as GPIO
and I am getting more expected results now. I think the gpiozero code might not have been picking the pin up properly.
one thing I am noticing though, the routine is not clearing out old notes from the queue like I would expect.
The following code makes me think it is supposed to be deleting the notification after it reads it:
def get_updated_file_info(card=nc):
req = {"req": "note.get"}
req["file"] = notification_file
req["delete"] = True
print(req)
rsp = card.Transaction(req)
print(rsp)
if "err" in rsp:
return None
else:
return rsp["body"]
But often if I go into assets and change the name of the file and run the file_notify.py, it will add a new note with the new filename, but I will notice the old one is still out there and when I run the get_update.py, it will often (not always) reload the old file.
Which file it selects Might have have something to do with timing. I was interrupted and came back after 30 minutes and subsequent tests started downloading the newest file
@gwolff Still having problems with the ATTN pin firing. Seems to be firing continually the way I have it written.
I switched from gpiozero to RPi.GPIO:
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BCM)
attn_pin = 6
GPIO.setup(attn_pin, GPIO.IN)
defaultProductUID = 'com.xxxxx.ayyyy:zzzzzz'
port = I2C("/dev/i2c-1")
nc = notecard.OpenI2C(port, 0, 0, debug=False)
notification_file = "file-update.qi"
But it seems that when I query the pin, later in the main loop, itās always high, even when nothing should have triggered it.
if (GPIO.input(attn_pin) == 1) and (timer() - ten_second_timer > 10):