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?
It seems at this time, the webp is the only item we can push to the device. … From the main post of this thread:
And…
I also ‘missed’ that the functional app could not be installed at this time (when I went through the SDK tutorial and API stuff) … but now I see why. I am looking forward to being able to have my own functional apps.
@kay, that is my approach. I’m using launchd on the Mac to render the webp every n seconds and push it to the device. I specify the -b flag when pushing to update the image in the background, so it does not get displayed immediately on the device. That maintains the rotation of the images on the device. So far it works well but running my script to do the rendering and push was kind of a pain to setup with launchd.
I’m doing this very approach for each of my apps, but running it from a VM on Google Cloud Platform. Render and push to the device every 5 mins. It’s disappointing we can’t do the processing in the cloud, but I understand this is still new and still being perfected.
I’m also rendering and pushing my apps to my new Tidbyt every N seconds/minutes. If you have a docker host handy, here’s my Dockerfile (a bit crude but works for my controlled environment)
FROM golang:bullseye
ENV WEBP_VERSION libwebp-1.2.2-rc1
ENV REPO=$GOPATH/src/github.com/tidbyt/pixlet
RUN apt-get update \
&& apt-get install -y ca-certificates tzdata openssl libwebp-dev bash
RUN apt-get update && apt-get install -y cron && which cron && \
rm -rf /etc/cron.*/*
RUN git clone https://github.com/tidbyt/pixlet.git $REPO && cd $REPO && make build
COPY entrypoint.sh /entrypoint.sh
COPY crontab /etc/crontab
COPY INSERTYOUR.star /INSERTYOUR.star
ENTRYPOINT ["/entrypoint.sh"]
CMD ["cron","-f", "-l", "2"]
You could COPY in your crontab/star or do a volume/mount for them.
Some other info / files you’ll need: Running Cron in Docker
It would be great to at least have some guidelines published for what an acceptable app will look like - at least in terms of inputs into the main function, what kind of config values are appropriate and how to handle them.
I’m working on an app for Strava, and I’m really interested in how the workflow should work for someone entering / approving the connection to their Strava account, and how the auth key / refresh token can be provided to the Starlark code.
Any guidance as to how often of a refresh is acceptable? If I am refreshing every 5 seconds all day… is that going to put too much load on the Tidbyt servers?
There’s no way to push directly to the Tidbyt without going through Tidbyt servers… so, not really any other options at this point…
@DanS are you getting your app to actually refresh after a certain amount of time? I can’t get mine to refresh, including the bitcoin.star example. I did open a separate issue here for this though.
@DanS That’s like 17,000+ pushes a day… I am just curious… what sort of app is it that you want 5 second updates?
I am interested in making some stock apps, and they can be pretty high frequency, if you like to watch the markets as closely as possible.
I am also looking at a satellite tracking idea and that might be pretty active at times.
@rohan can you tell us what sort of plans you have for supporting the user base when they want to implement all these ideas? Do you see it being better for us to generate our own images at high rates and push them through, or having TibByt servers to do the processing and send the results, or will it be the local device that does the work?
Super pumped to see the Aircraft applet! Technically, if we don’t rate limit you we support it. On the flip side, please be nice to our services. We pay per push - so if we get a lot of folks pushing so frequently, we’ll need to implement stronger rate limits across the board.
Pushing updates every 30-60 seconds feels more then adequate to get up to date aircraft information. Unless of course you’re trying to use Tidbyt for an air traffic control tower in which case I’d have to advise against that .
Understand. What would be good is a way to get the tidbyt to hit a URL (with parameters) that returns a webp file… or allow a direct push to the tidbyt from the same IP network… that way it all stays local and doesn’t stress your servers. (I assume you’re using AWS?)
I can also write it so that it only pushes when an aircraft is within 1-2 miles or so.
.
