Access data on LAN

Hi, I’m thinking about backing the device on Kickstarter, and was hoping to write apps that can access data-sources in our company LAN (firewalled, not accessible from the internet at all). Things like code-repository / build servers, monitoring internal deployments.

I tried to read through both the SDK and API pages, but this is still unclear for me: are the apps running on the Tidbyt device itself, or are they running in your server infrastructure (and the output images are transferred to the device)?

Thanks,

–HaZse

2 Likes

I think you’d need to write your own firmware to do this. I’m working on some firmware for a smaller display device which will allow datasource from mqtt or other http server.

Hey @HaZse, apologies for the delayed reply.

Yup, the way it is currently, everything runs on our backend. The exception is Pixlet apps that you can run locally and then push the rendered output to your device via the API. However, that rendered API is still leaving your network and entering ours before going to the Tidbyt.

This is more of a software limitation than hardware. With v1, we focused on the 90% use case and it’s just much simpler to code for all the data coming from one source. If there’s enough demand for it, I’d be open to adding some sort of completely local communication. We would have to figure out what that looks like and how it works though.

6 Likes

Hi, sorry for my late reply now :slight_smile: For my use-case the Pixlet + push API route will work, there will be nothing secret on those images.

For the use-case where the content is secret: maybe you could implement a feature where each device would have a unique encryption key (either generated on the device, or during the initial setup on the phone), and we could use that key to encrypt the payload pushed.

Yeah that would work actually. There is a secure crypto element on each device, which we’re not currently using but which we could use for something like this.

Of course in the end a lot of it comes down to how much you trust us. For example, not that we would, but if we were evil then we could send a firmware update that just pushes back that decrypted stuff to the server! If you’re paranoid, I think the only way to be 100% sure of the security and privacy of any device is to build it from scratch, or at least write your own firmware from scratch.

So I definitely see value in the local communication story, for devices or things that can only be reached on the local network. But if it’s top-secret data that nobody can be trusted with… that’s a bit harder to figure out.

1 Like

Main use case (or concern) I have for interacting with the device locally is to remove dependency on any external backend. There are plenty of examples of device makers simply going out of business (hopefully not in this case - but you never know), being acquired by another company that then kills the service or worse deprecating an older device so they don’t need to maintain their older code base - in all cases this leaves customers with a brick. One suggestion, do you have (or maybe already) plans to opensource the backend? That would be an easy route to solve these concerns plus the security/privacy angle others have mentioned, as it gives an option to spin up a local backend.

3 Likes

hi Rohan,

this is pretty important to me as well – I live in a 25’ Airstream trailer and definitely cannot be assured that I’ll have internet access at any given moment, but really want to use a Tidbyt as a general status display for the trailer. among other things the case perfectly matches the decor in here :slight_smile: I hope this adds another “+1” to the need for local-only functionality.

2 Likes

what kind of trailer information are you wanting to display ?

1 Like

I have a similar use-case; i want to display information about my rural home’s solar power production, battery level, power consumption etc. All this data is local only, and in the event of a power outage there’s no internet. My home will still have power, but suddenly managing that power becomes critically important
Im not sure what security issues this presents since the device is basically just a display headend, yes? Require local configure changes to use a QR code or one-time generated PIN or Bluetooth only and that’s probably enough.

You’ll need to wait for the hardware development kit to be released before you can get the tidbyt to display data without a connection to the tidbyt servers.

Any update on this? I know you’ve focused on what you’ve seen as the primary use case first off, and that makes sense from a business perspective.

I have no idea what internal discussions you’ve had so far, but I’d like to pitch 2 features:

  1. An authorized push endpoint on the unit’s local network interface to update a specific installation id’s data.
  2. The ability to poll an external endpoint, providing headers/payload data.

I think these two basic building blocks would be pivotal in creating a richer ecosystem and integrations into other automation-capable systems.

P.S. Congrats on the Zapier integration, btw! :muscle:

1 Like

Is there any chance you’d release your firmware publicly so we could fork it and add these features?

2 Likes

Any update on this? I know a lot of folks with local-only smart devices (solar, water tank levela, temp) they’d love to have on an ambient info device like the tidbyt.

I’m working on a tidbyt app manager web app that might help with this.