allow RPi to be accessed remotely #4
Comments
|
let's do these daily and hourly, so that they can just be plopped in /etc/cron.daily and /etc/cron.hourly as shell scripts. right, @gabe-ochoa? the ops_tools sync would just be: and the shipping label/printing one will be whatever you give me, plus the printing line: |
|
^ formatting on the first of these got messed up, should be multi-line. |
|
I'm for doing both every half-hour. No reason to have new code or changes wait around too long without getting pulled and we don't want to make AA wait a whole 24 hours if something is wrong for a fix. We can control the labels timing remotely a little bit by changing when we do the pull on Squarespace orders on the coordinator. |
|
👍🏻
On Mon, Sep 4, 2017 at 10:23 Gabe Ochoa ***@***.***> wrote:
I'm for doing both every half-hour. No reason to have new code or changes
wait around too long without getting pulled and we don't want to make AA
wait a whole 24 hours if something is wrong for a fix.
We can control the labels timing remotely a little bit by changing when we
do the pull on Squarespace orders on the coordinator.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADvIKI7cuLMNvpbk2IcZ9OLdgHYxqtqqks5sfAfagaJpZM4PLZ_w>
.
|
pencerw
changed the title
|
Why make this automatic at all? I'd think these kind of changes would be a big, rare, and thoughtful events. Having a couple of intentional interlocks between an accidental push on the wrong branch and wrong stuff going out the door would be a nice. |
|
@bigjosh the shipping label download would be nice to have automatic because it alerts Accelerated that we have orders, hopefully increasing the chance that we get 1-day shipping. We can probably do this some other way but cron seems like a reasonable first method. What's the alternative re: pulling new code? We'd need some method of triggering a pull from outside the RPi's LAN. |
|
Only talking about making process changes (via How does... ...this actually happen? Where does the data from the labels get downloaded from? |
|
@bigjosh roger :) i kinda figured that, but just wanted to be clear.
|
|
👋
Another (albeit long-term) reason to have the labels printed on a cadence is that when the public radio is sold on other sites (the tpr squarespace site or another retailer) the new orders will come in on a rolling basis. It would be great to be set up to process these orders automagically and have them printed at the warehouse as a sign that a radio needs to be shipped with us having to take a manual action.
…--
http://gabeochoa.com/
Phone:
tel:512-826-5402
Email:
mailto:[email protected]
On Mon, Sep 04, 2017 at 11:55 PM Spencer Wright < mailto:Spencer Wright <[email protected]> > wrote:
a, pre, code, a:link, body { word-wrap: break-word !important; }
https://github.com/bigjosh
roger :) i kinda figured that, but just wanted to be clear.
how would the manual process work? we'd need to do it remotely from outside the LAN, as these Pis are headless and (until we get a better read on Accelerated) are our responsibility to maintain and manage. also, just to be clear: we're keeping one of these systems in NYC, and i'm assuming that it would be used to test everything in a dev branch before pushing to production. given that, is there really that big of a difference between "deciding that we are ready to push to production, and knowing that the RPi in Chicago will update in the next 30 min" that different from "deciding that we're ready to log in somehow to the RPi in Chicago to pull new code"?
from
https://github.com/gabe-ochoa
! the tpr_coordinator (
https://github.com/The-Public-Radio/tpr-coordinator
) takes in orders and creates shipments via Shipstation - which returns PDFs of each of the shipping labels. the coordinator will store those PDFs until a RPi pings it, asks for anything that hasn't been printed yet, prints them (
$ lpr -P <dymo 4xl printer name> <pdf filename>
) and then tells the coordinator that they've been printed. we
had
thought that we'd use Shipstation Connect for this, but it turns out that it's impractical and doesn't allow us to build "shit happens" contingencies into the system either.
—
You are receiving this because you were mentioned.
Reply to this email directly,
#4 (comment)
, or
https://github.com/notifications/unsubscribe-auth/AEaHSvu2ED49AsNgOEMUbKHiaesj2fquks5sfMZIgaJpZM4PLZ_w
.
|
|
Sorry, I don't understand the information flow for the orders.
-josh |
|
No problem - grab from tpr_coordinator, which is running on Heroku
On Tue, Sep 5, 2017 at 02:29 Josh Levine ***@***.***> wrote:
Sorry, I don't understand the information flow for the orders.
grab all unprinted shipping labels and print them
Grab from where?
-josh
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADvIKGhEWXuo2VRkTwCw3ZNrz3hFX_Icks5sfOpRgaJpZM4PLZ_w>
.
|
|
@bigjosh bumping this:
|
|
This recently got much easier... These will let you easily SSH onto the remote machine. Dataplicty has an especially nice interface that you can run from your phone. You feel a little like Superman when you can get a text about a fire, pull out your phone, SSH in to put out the fire, and put your phone back in your pocket before the light turns green. :) I'm still a little confused as the to the relationship between your pull frequency and live orders getting sent. Am I missing something? |
|
@bigjosh interesting, will look into them! re: the coordinator: there are a few ways that orders get into the tpr_coordinator database. @gabe-ochoa has an import script that takes in a CSV (or something); we also will develop (TBD) a hookup to the Squarespace Commerce API so that any new orders that come in through our site (which is not currently taking orders, but eventually will) will get pulled into the tpr_coordinator database on a rolling basis. the second step is that @gabe-ochoa has tpr_coordinator linked up to our Shipstation account. so the coordinator is periodically (gabe, fact check me on the actual details here) looking at all the new orders that it has and telling Shipstation about them. Shipstation takes in all of the order details and creates USPS shipments from them, then returns a PDF (the actual shipping label for each shipment) and a tracking number (a 22 digit number that's also printed as a barcode on the label) to tpr_coordinator. so now the database has all these orders (some of which were imported via csv from our kickstarter database, some of which came in automatically via commerce APIs, some of which may have been created manually by yours truly so that we send samples out to radio stations, etc) and each order has a PDF associated with it AND a tracking number as well. NOW, the RPi at Accelerated has to get them. so, this cron task wakes up every half hour (or whatever) and asks the coordinator: "are there any shipping labels that i have NOT printed yet?" and the coordinator replies "here's one," and the RPi accepts it and prints it on a DYMO 4XL printer that is plugged into it, and then says back to the coordinator "I successfully printed that label," and the coordinator marks that label as printed in the database, and then replies "also, this label hasn't been printed yet," and the process repeats until everything's been printed. [note, there's some yet-to-be-completed error handling here, namely that eventually the DYMO printer will run out of paper, or a label will be lost, etc. we'll hopefully be able to address these cases in the next week.] so now all the orders in the database have tracking numbers, and they're marked as "label has been printed." and on the floor in chicago, there's a whole spool of shipping labels that need to be processed. let's say this is monday morning, and assume that they get them all done on that day (side note, every time they put one of these shipping labels on a box they rescan it and Tulip tells the coordinator "hey, the shipment associated with this barcode is now "BOXED"), and that no new orders come in until tuesday at 1135. well, then on tuesday at noon this cron task will run again, and it'll ask the coordinator for any unprinted labels, and the whole process repeats. sorry for the ramble - i think that covers most of it. make sense? |
How does this actually happen? An http request to a directory full of PDFs? A dropbox? |
|
@bigjosh check out this script: https://github.com/The-Public-Radio/ops_tools/blob/master/print_labels.sh When run, it downloads a base64 encoded PDF which is the shipping label from the TPR Coordinator for each shipment that has a label created but not printed. The script then sends the label to the print queue and once printed updates the TPR Coordinator marking that label as printed. Labels are created synchronously via the Shipstation API when orders are loaded into the TPR Coordinator. This happens 1 of two ways right now:
|
|
FYI - i'm actually able to remotely log in to the RPi and was able to install dataplicity. i can confirm that it's installed and running, but it doesn't seem to be communicating with the remote server. i suspect this can be solved with port forwarding, and should be able to set up a solution next week. in the meantime, it's relatively easy to run remote commands (like git pull, make, etc) on the RPi via Tulip. the only caveat is that:
regardless, i should have a solid solution on this soon. |
pencerw
changed the title
|
Sadly, Dataplicty can be a bit flaky- but it is so damn handy when it is working that you forget about the flakiness. That's why I always also install Remot3.it so I can have a backup way in when Dataplicty is flaking out. |
it should do a few things:
The text was updated successfully, but these errors were encountered: