API TLS Handshake Timeouts

Hi there,

Over the past week, I’ve been noticing some API errors when using pixlet push, and I’m wondering if this is related to an issue I started noticing at the same time of my Tidbyt becoming “stuck” and failing to receive/render new updates without me restarting my looping Pixlet push script. This isn’t an authentication issue, as my API token and device ID are correct and work when I restart my script (only to then fail again sometime in the next day, typically).

Here’s the precise error I’m seeing on the command line that occasionally crops up: pushing to API: Post "https://api.tidbyt.com/v0/devices/[my-device-id-here]/push": net/http: TLS handshake timeout

One thought I had is that perhaps there’s some new rate limiting going on on the Tidbyt API? I’m currently pushing an update every 10 seconds, FWIW.

As a follow-up, I am now getting a new error, {"code":16, "message":"token is not active", "details":[]}

I double checked things in the app and I’m using the correct token and device ID as provided there. Any idea what’s up? As it is, my custom Tidbyt app is currently unusable =\

I think this is a bug with a new authentication method we rolled out. I’m rolling it back now.

1 Like

Thanks Rohan. That fixed my token issue and I can once again push updates :+1: I’ll report back here if I notice the timeout issue reoccurring.

FYI for anyone else seeing this: I was still getting these timeouts even after the authentication fix from Rohan, and for whatever reason they were breaking my (very simple) bash looping script to push updates to the device. I took a new tack and wrote a simple Node app to re-render and push updates, but only whenever the screen’s content has changed, and this seems to have fixed the issue for me (and is a lot nicer on the Tidbyt API as well).

You can see the details of that app in my post over in the Developers forum: Strategies for Self-Hosted Apps? - #5 by CyberMonk