-
Notifications
You must be signed in to change notification settings - Fork 525
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Misc. Discussion (Technical) #9
Comments
I spent some time with the code and think I have the hang of it (I also learned some new things in doing so) - really nice job Ben! Regarding the issue I posted a couple of days ago, this is starting to look like something hosting related. To briefly recap, it seems that the remote monitor intermittently fails to get updates. At first it seemed related to the Share app losing data (turns out my compute conservationist daughter was killing the app out of habit, which I have since untrained her to do). With that addressed, the issue seems to persist despite Share running in background which is strange. When I run index.js locally, the data is uploaded to the API as expected. I even reduced the interval to 30 seconds for testing and it works fine (though I do wonder about rate limiting/throttling on the Share API). 4 times out of 5, when the issue arises, I can "fix" by restarting the Website (OK Web App now). Is it possible that Always On is required for the bridge to work as expected? If so, I wonder if setting a recurring schedule might be a solution to requiring upgrade to more expensive hosting plans? |
Good job pulling into new thread. It is very possible that this is required. The deploy to Azure instructions are now here: Anyone can edit this page and include pictures, here's a few I found on Facebook: |
I had the same experience using Azure and was able to successfully run it using 1min intervals without the process stopping on Azure. I also have been running it on Heroku for over a week with no problems on a free 1 Dyno plan with 1 min intervals. I am actually running 2 separate instances of the process - 1 pointing at an Azure site and 1 pointing at a Heroku site. Seems to me that Heroku for the bridge code seems like a better solution, even for people running Azure sites. |
@bewest yep, I see that now- thanks for pointing it out. I've reduced the interval to 30 seconds and so far so good... I'll report back in a day or so. @toarikaplan What are the advantages of Heroku over Web Jobs in this scenario (other than cost)? Are you running Heroku natively or doing something like Dokku on Azure/AWS? |
Heroku native. Couple of minor advantages other than cost, though I still use Azure also. Heroku overall has had less downtime in general, has a handy free mobile (iOS app) and it is setup to point to a website so that I can point it at NS Azure setup or NS Heroku. I also setup a second job that runs once per hour and collects 150 readings to fill in if the phone disconnected (dead batt, killed app) which is easier to manage with a setting than changing index.json. |
So I got the dashboard and bridge up and running on Heroku before leaving on a trip this weekend as a test and the bridge has run flawlessly not stopping a single time which is a huge improvement over having to start the job a couple of times on free/shared. This is with a single dyno which as @toarikaplan points out is 100% free so I have to agree that Heroku is a better option for Sidecar. I've since moved everything over including the Pebble API and it continues to run perfectly. Perhaps a dedicated Heroku tutorial is in order to help some of the less technical folks get up and running. Thanks for the recommendation @toarikaplan ! |
Glad it is working for you |
Starting a new thread so I/we don't spam the tutorials with technical discussion.
Ben/team: If you prefer a different medium, please let me know.
Thanks.
The text was updated successfully, but these errors were encountered: