@tget4 This is what my curl request looks like:
curl --request GET \
--url https://api.tidbyt.com/v0/devices/<DEVICE ID>/installations \
--header 'Authorization: <API KEY>' \
--header 'Content-Type: application/json'
@tget4 This is what my curl request looks like:
curl --request GET \
--url https://api.tidbyt.com/v0/devices/<DEVICE ID>/installations \
--header 'Authorization: <API KEY>' \
--header 'Content-Type: application/json'
@Millsionaire make sure you are adding Bearer
to the Authorization header
Authorization: Bearer <API-KEY>
That was it. Thank you!
I love your community repo idea. I’m a developer at a company that does something similar – we have a community repo that anyone can make PRs against to update their own code or even someone else’s, and our paid developers review it before pushing it into the wild. But in our case, even if you wrote the code, because of the nature of the product it’s kind of “community property”, and I don’t think that’s the case here. It would have to be a little stricter on who can update what. I wouldn’t want strangers deciding that they don’t like the size of the image on my app and just making a PR on it with no permission from me, you know?
Anyway I made this little app that pulls a random reddit post from a list of subreddits that a user would define on their phone, gets a random image post from the list of hot posts, and displays it with the title, subreddit, and ID.
It would be cool if this was an app, because the way things are pushed right now, I would have to run a script constantly on my macbook to update the actual post it’s displaying and my Macbook isn’t my main machine so it’s not on most of the time and none of this works on my Windows machine at all. It uses the public Reddit API, so there’s no concerns about permissions, and the only user configuration it needs is a list of subreddits to pull from.
I just want to give you guys my code so I can get that sweet sweet dopamine of cats in ties popping up on my device. Thank you for your cat-tie consideration.
@dmc I think I’d prefer the inverse of this. I’d like a webhook app where I can configure an endpoint to make an HTTP request every time the app is ready to display (with DeviceID/InstallationID in the payload). This endpoint would live on my own infrastructure and would be responsible for returning a webp/gif/jpg. Then there’s no worry about Tidbyt managing my code or worrying about DDOSing their APi
The great thing is both ideas aren’t mutually exclusive, so both could be supported, giving developers flexibility of the model they’d like to support
The reason I suggested the “developer push” model is that the current API is fairly close to supporting it. You could do “developer push” with the webhook version as well: if Tidbyt offers the option of triggering a pull, then you can use Tidbyt for time-sensitive updates.
I’m interested in the breaking news, someone just went live, real time notification possibilities of Tidbyt and would be disappointed if there’s no possibility to say “I want to show this up now” type notification (as I type this, there is a feature request in the suggested topics for PagerDuty notifications, which would likely require this type of usecase)
I made an app for MBTA transit times. (I’m not sure why the built-in transit app doesn’t include MBTA bus routes, only commuter rail.) I wouldn’t mind contributing it to a shared repository, but there needs to be some mechanism to pass secrets like API keys.
I am trying to publish a custom written application, and when attempting to push as documented, the application still isn’t sticking in the list of installed applications.
pixlet push --api-token <YOUR API TOKEN> <YOUR DEVICE ID> examples/bitcoin.webp <INSTALLATION ID>
I’ve attempted to push this using the following formats:
pixlet push --api-token <YOUR API TOKEN> <YOUR DEVICE ID> examples/bitcoin.webp TEST ID
pixlet push --api-token <YOUR API TOKEN> <YOUR DEVICE ID> examples/bitcoin.webp "TEST ID"
pixlet push --api-token <YOUR API TOKEN> <YOUR DEVICE ID> examples/bitcoin.webp installationID=TEST ID
pixlet push --api-token <YOUR API TOKEN> <YOUR DEVICE ID> examples/bitcoin.webp installationID="TEST ID"
None of these options are working. What is the proper way to send in this installation ID to keep the application saved?
The installation id must be alphanumeric, so nothing besides letters and numbers, so try
pixlet push --api-token <YOUR API TOKEN> <YOUR DEVICE ID> examples/bitcoin.webp TestID
I have also tried this - it also did not save. It displayed once and never again.
I just tried that exact command but with my API token and device ID, and it stuck, so I don’t know what else might be going on. Does it show up on the phone app? Did the push command print any message?
No message is printed. It immediately is sent to the device and displays, and then never shows again. It isn’t showing on the phone app at all. Unsure what’s going on.
Did you build pixlet from source? Hopefully I’m not mistaken since it worked for me, but you may need the latest code for this feature, so make sure to build from source:
I have the same issue when I use Pixlet push command - funny enough it worked once when I added at the very end after my HelloWorld.webp << “installationID”: “HelloWorld”>> then it did appear as Application in the Mobile App ONCE - but neither displayed it on Tidbyt in a re-occuring cycle nor could I repeat that after when using the exact same shell script.
Yes, I have tried both the already compiled version and the one built from source. Neither appear to work for me.
Edit: I have just rebuilt from source for the third time, and it now appears to have fixed the issue. I don’t know why it didn’t take the newest build before, but all appears to be working now. Thank you for the help with this!
Thanks!
This is easily overlooked in the docs: the example given is just “123”.
Maybe “Bearer 123” would be better?
Yes, please fix this in the docs, it is not an easy error to figure out.
A public repository would be great! How well it will last over time is anyone’s guess.
So many projects over the years have had the ‘plugins’ mentality, and lots of great developers worked hard to make cool stuff… then the primary software evolves and things just break down and don’t work anymore.
Having a cool continuous integration environment can help. Having a feedback system that provides emails to contributors when the code fails to ‘build’ on the latest generation of the system would be good.
The effort to manage and maintain the repository is an interesting challenge. Having a donation option to help offset your costs would be an option, kinda like opensource support fees, but not a pay wall.
Making some contributors able to get donations for their contributions would be awesome, as long as, again, it does not become a paywall. [I don’t think/feel that is the spirit of Tidbyt.] Only something to motivate developers (by the consumer) to help keep things working over the long term. Maybe like Thingiverse’s ‘tip’ option where one can PayPal something to a designer as a friendly contribution for their efforts.
I am having fun with my Tidbyt, learning to deal with GO/Starlark, etc. I can see publishing some of the stuff I have done, for everyone to use. I am looking forward to the HDK, and that would be another dimension to the contributor site as well. Content could be a whole section, Icons, images, color schemes, frameworks, there are lots of areas that folks could contribute to the community.
I don’t think the licensing has to be complicated. Pick the most relaxed one, and only by agreeing to total disclosure and openness can a contribution be allowed. No pre-compiled stuff, no encoded/encrypted stuff, all free and open to modification by anyone that chooses to. If someone wants a proprietary app, that is fine. They shouldn’t post it to the community. They can have their own Shopify store or whatever to sell their stuff. Maybe?
@mark It does not appear that this update has been pushed to the latest compiled version in the git repo. When will the next full release via git take place for us to install this new update via Hombrew?
This is fixed in all the examples now, sorry about that. The API test tool in the docs automatically adds Bearer
now too.