Push Formats (star)

[joeyhoer]

It looks as if the only format the API accepts for the push command is webp. Is it possible to push a star file, and configure the refresh interval on the Tidbyt?

Example: I’m writing a clock app (as you have in the README example). When I render and push this, the Tidbyt will only display the one image (it does not update automatically when the minute changes). Do I need a server to render and push the star file once every minute to keep the display up to date? OR should I try to build the clock “app” (which is actually just a webp) such that it includes 720 frames (or 1440 frames for 24 hour time)?

[zenahirsch]

I am wondering about this as well. I have an app that pulls data from an external API, and would like to install the app on my Tidbyt so that it automatically updates.

[allidoisace]

I am having the same problem right now and I am not sure how their current crypto apps are doing it. I made a custom app to get the price of a particular crypto following the bitcoin example and once its pushed, the price doesn't update anymore.

[vonnieda]

It appears the Tidbyt just requests a new image periodically from the server, which renders it at that time. As far as I can tell the Tidbyt does not run the Starlark runtime, and instead just requests animated images to display. Given that, I don't think the current firmware can run anything that updates regularly without going back to the server.

[allidoisace]

So, can we have a server that periodically pushes to it? I would much prefer this.

[joeyhoer]

@vonnieda is correct from what I gather. I don't believe the hardware exists to save and execute Starlark files directly on the device. For more information, checkout this post in the community forum—Publishing Apps—which states:

The way our backend works is we load up starlark files using the same rendering library available in Pixlet. Every time an app needs updated, we execute the starlark on our servers and send the result back to the appropriate device.

Basically all the rendering happens in the cloud, which (IMO) is an ingenious way to keep hardware costs down, but also means the device essentially requires a constant connection to Tidbyt's servers. If your WiFi is down, or their server goes offline, the device becomes a beautiful wooden paperweight.

Right now, you have to roll your own solution to push app updates at regular intervals. You can see that an SDK for publishing apps is on the platform roadmap.

[allidoisace]

Yeah so I am going to try just looping in the star's main and re-render each time it for API request (like every 4 minutes) or something. If that doesn't work, then I guess I will run some serverless option to POST to the API to update the webp.

[allidoisace]

Obviously this isn't endorsed by tidbyt, but pretty interesting what I found.
https://github.com/drudge/homebridge-tidbyt

[betterengineering]

Hey folks! So sorry for the delay here.

Push Formats

As you all have mentioned, we can't accept arbitrary starlark just yet and @joeyhoer called out the appropriate thread on why in Publishing Apps. One thing we can do is add a flag to render before push. Right now, you have to do:

pixlet render examples/bitcoin.star
pixlet push --api-token="$TIDBYT_API_KEY" "$TIDBYT_DEVICE_ID" examples/bitcoin.webp

It would be nice if you could simply run the push on a starlark and pixlet would render it for you as part of the same command:

pixlet push --api-token="$TIDBYT_API_KEY" "$TIDBYT_DEVICE_ID" examples/bitcoin.star

Running Custom Applets

If you want to add an applet permanently to your rotation, you need to add an installationID. In practice, you'll also want to push updates in the background to not interrupt your current rotation. A very simply way to do this would be to render and push every 60 seconds in a loop:

#!/bin/bash

while true; do
	pixlet render examples/bitcoin.star
	pixlet push --api-token="$TIDBYT_API_KEY" --installation-id="Bitcoin" --background "$TIDBYT_DEVICE_ID" examples/bitcoin.webp
	sleep 60
done

Clocks

@joeyhoer for your specific case of building a clock, it gets more tricky. You could use a solution like the infinite loop shared above, but you'll want to push closer to every 30s or maybe even every 15s to ensure the clock stays up to date in your rotation. You will need a server and I'd highly recommend against rendering a really large webp to include time for the day 😄.

The way we handle this internally is a bit more clever. We figure out when the Tidbyt will show the clock next and render the clock just-in-time before sending it back to the Tidbyt for display. If you want, we'd be more then happy to vendor your clock with attribution before we get the community apps repo up and running.

Custom App Server

What would be nice is if we had a custom app-server built into pixlet. I don't suspect Pixlet will be anywhere near as feature rich as the Homebridge Plugin any time in the near future, but being able to run Pixlet as a server would be a nice feature.

I imagine it would watch a directory of applets and push updates on cadence. Effectively, the infinite loop but more then one applet and built into pixlet natively. The command might look something like:

pixlet app-server --api-token="$TIDBYT_API_KEY" --device-id="$TIDBYT_DEVICE_ID" examples/

It would then render and push every starlark file in the examples directory every 60s. You would still need to run a server somewhere, but at least all of the logic would be taken care of for you.

Feedback Wanted

Have any thoughts or questions? Let me know and I'll be sure to get back to you! I'm going to leave this thread open for a few more days and will close it when activity dies down a bit.

[joeyhoer]

@betterengineering My personal solution—and as I understand it, the right way™ to run scheduled jobs on macOS—is to use a LaunchAgent (as opposed to a cronjob). Though a sleep loop shell script, or a cronjob should also suffice.

This is what I've been using (placed in ~/Library/LaunchAgents/; note that the ellipsis are replaced with the appropriate user path):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>Label</key>
    <string>com.localhost.tydbit.render</string>
    <!-- Ensure sh and bash have been given Full Disk Permissions -->
    <key>ProgramArguments</key>
    <array>
      <string>sh</string>
      <string>-c</string>
      <string><![CDATA[cd "/Users/…/tidbyt-apps" && ./render.sh]]></string>
    </array>
    <key>EnvironmentVariables</key>
    <dict>
        <key>PATH</key>
        <string>/Users/…/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin</string>
    </dict>
    <key>RunAtLoad</key>
    <true/>
    <!-- Run at the top of every minute -->
    <key>StartCalendarInterval</key>
    <array>
        <dict/>
    </array>
    <!-- Ensure /var/log/localhost is writable -->
    <key>StandardErrorPath</key>
    <string>/var/log/localhost/tydbit.render.log</string>
    <key>StandardOutPath</key>
    <string>/var/log/localhost/tydbit.render.log</string>
  </dict>
</plist>

This has been working well for the clock, but if there is any network issue, the time isn't updated, which isn't ideal for a clock. I agree that a 1440 frame webp for the entire day is overkill (I've already encountered some AWS file size limit restrictions), however a webp with enough frames for the next hour could help smooth out any temporary network issues, and also (potentially) require less frequent pushes/network activity.

---

I would be glad for you to vendor the Big Clock app—let me know if you need me to break it out into a separate repo or add an Open Source License file (or any other specific License which will allow you to vendor the code). I recently updated the app to support configuration variables which should be helpful in vendoring the app; feel free to change the code as necessary!