As far as I can see in the firmware code it has Arduino under the hood. And the firmware itself doesn't look that complicated. If I'm ever buying one I'd definitely rewriting the api client to my liking:)
this post was submitted on 05 Feb 2025
111 points (95.1% liked)
Open Source
32570 readers
262 users here now
All about open source! Feel free to ask questions, and share news, and interesting stuff!
Useful Links
- Open Source Initiative
- Free Software Foundation
- Electronic Frontier Foundation
- Software Freedom Conservancy
- It's FOSS
- Android FOSS Apps Megathread
Rules
- Posts must be relevant to the open source ideology
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon from opensource.org, but we are not affiliated with them.
founded 5 years ago
MODERATORS
$20 to unlock the API killed it for me. If it has a built in way yo lock it down, it's not an open platform and is a great way for bugs to brick a device.
This is a really bad way to look at an Open Source project. Want an API for free? Host your own, they have a server you can run. They are providing that service as a hosted platform, that they pay for, so you don't get that part for free. That's not what FOSS is.
Two issues I have:
- There is a license on what you can install on the device. Open means no licenses on owned things, regardless of how open that license is initially, it can be changed.
- The server it connects to is not configurable. You have to build your own firmware and maintain it and that goes back to the first point in case they decide to change the license.
-
You can compile whatever you want into the firmware and load it on the device.
-
The server is configurable, by loading new firmware. It's just like flashing an ESP32, which you could also build your own TRMNL out of.
In other words, those are not real issues.
But i have no desire to compile and maintain a fork of software just to set a URL and auth token. And again, this is a license to modify the firmware, so they could at some point decide to revoke the license to modify the firmware or stop publishing security updates on their git repo to allow for merging into the fork I have to maintain. Probably won't if they are reputable and don't get acquired, but still a risk. It's just not worth it for me for any open product I purchase.
You should probably stop complaining about FOSS if you don't understand how it works.
i have no desire to
So? Then don't, but don't claim the $20 is your issue. Firmware is easy, you just don't want to learn it.
they could at some point decide to revoke the license
Nope. They need approval from all contributors to change, and even if they got that, anyone could fork from the time of the current license. This is how FOSS works. Lemmy itself could do the same thing.
It's just not worth it for me for any open product I purchase.
What open products are you purchasing that you think don't follow this pattern?
I said from the beginning it's a deal breaker for me. You're the one trying to convince me it's not the issue I think it is.
And I'm not talking about the license to modify the firmware software itself. I'm talking about the EULA of the device itself. Pretty much any device you own that has any kind of software on it is not owned by you outright to modify as you wish. This website doesn't show the agreement, but if it has a paid feature to unlock, it has to have one somewhere.
Charging a one time fee for the API seems like a decent way to ensure continued operation.
But if you don't like it, you can run your own server
Problem for me is that there is some kind of restriction on accessing the device's API at all and you pay extra for the key that will get created when you unlock it. This may mean that some kind of lock is in place on the device that has to have a key for it created. Even if they give you a key, what happens if an update removes that key's validity, even unintentionally. I've had this happen with products in the past. A bug will restrict access to things or worst case, will totally brick the device because the lock is stuck in place.
Not saying this device has that problem, but the concept of a lock existing means it could intentionally for profit, maliciously by hacking, or unintentionally end up locked later, so I'm just against the concept in the first place. It's a potential point of failure for no good reason but profit on a device that is supposed to be open. I'd happily accept if they changed a little extra for a device that had no lock at all. Just I don't want a device with a lock on it.
Also, I'm not sure how having my own server helps here, in fact that's my plan in the first place as I want to get the thing to interface with my own internal systems. Maybe I'm misunderstanding the implementation, but my understanding from the very brief information available is that you get on your device, connect to their server to pay a fee, and then a key is created for you and then you can access the endpoints running on the device either through the server or directly with REST calls. The alternative is to teardown the device and build your own custom firmware that uses different authentication mechanisms. I don't really have the interest to mod the firmware and then have to maintain a fork for getting official updates. I just want to be able to be able to interface any servers I have with the device as I choose.
Maybe I’m misunderstanding the implementation, but my understanding from the very brief information available is that you get on your device, connect to their server to pay a fee, and then a key is created for you and then you can access the endpoints running on the device either through the server or directly with REST calls.
There are no endpoints running on the device. The API endpoints are hosted on their server. The device just sends requests to their server (or yours if you change one line in the firmware) for a bitmap image and a time it should wait until the next refresh. Then it goes to sleep until the response said it should make it's next request.
The alternative is to teardown the device and build your own custom firmware that uses different authentication mechanisms. I don’t really have the interest to mod the firmware and then have to maintain a fork for getting official updates.
No teardown necessary. Just plug in a usb cable and connect it to your pc.
OK, I see. They decoded not to have the device respond to requests. It's not that the device has endpoints, it's that it's hard coded to connect to a specific endpoint and you have to build your own firmware in order to get it to connect to your own server.
That's still a deal-breaker for me. It's just that the connection is flipped. I don't want to have to build and maintain firmware to use the device in addition to maintaining the server. Why can't this be a setting on what server it connects to?
You're right, they could. This issue was opened 2 days ago.
EDIT: From this comment, it looks like they're working on it
Checked the site quickly and didn't find the information, but judging by the top-level comment, they don't charge you if you want to use their cloud service, but if you want to "unlock" the ability to use someone else's.
not quite.
If you buy their device, the cost to use their service is built-in to the cost of the device, so you get access to their service and all of the 3rd-party plugins at no extra charge.
If you would like to write your own plugins for their service, or access their service on one of their devices, but with custom firmware, you need to pay $20 one time for an API key to get access that is more flexible than the limited way the stock firmware communicates with their service.
From looking at the source code of the firmware, it seems like you can extract the "API key" that gets generated by your device with the stock firmware and would technically be able to hardcode that in custom firmware, but I don't know if that gives the same level of access as the official API key that you pay for or if it against any TOS or anything.
If you are hosting a server yourself or are accessing a different server, you can very easily flash custom firmware that changes the target server, and there is no charge for that from TRMNL. The $20 is to pay for extra API calls to their servers over the lifetime of the device than what they accounted for in the purchase price.
In their documentation, they also briefly mention a recurring charge for API access if you want to use a DIY device with their hosted service, but I didn't see any mention of that anywhere else as the documentation for DIY devices is yet to be fleshed out.
This is very similar to what Home Assistant offers as a paid service. I don't see this complaint thrown at them, though. Also, any system that uses authentication has "a built in way to lock it down".
No, with home assistant they have a cloud server that has additional functionality that you can use or not. Home Assistant doesn't restrict access to the software on device it's running on.
With this, the device itself will not allow you to access its API endpoints without having a key that you need to purchase. And though they say it's a one time purchase, who's to stop them from releasing a critical security patch that invalidates the keys, even accidentally, or includes making the keys a monthly subscription going forward. Or what happens if that key gets exposed and you need them to generate a new one? Do you need to pay for that or is the device permanently compromised unless you build your own custom firmware?
You're allowed to modify the firmware to use a self hosted server for that functionality without violating the license, which is better than nothing, but then it's up to you to maintain your fork of the firmware. Why not just only require the key if you're connecting to their server and allow you to select your own server without needing to modify and maintain a fork of the firmware?
No, with home assistant they have a cloud server that has additional functionality that you can use or not. Home Assistant doesn’t restrict access to the software on device it’s running on.
That is also the case here. Both require self-hosting your own server that is open-source for free use. Both have paid cloud services with extended functionality. The differences are that Home Assistant always requires self-hosting, and is not set up with cloud services by default, while TRMNL is set up with (free as in beer) cloud services by default which can be extended with more functionality for a fee, and doesn't require self-hosting if you use their cloud services.
You’re allowed to modify the firmware to use a self hosted server for that functionality without violating the license, which is better than nothing, but then it’s up to you to maintain your fork of the firmware.
Sure, maintaining a fork is a bit of overhead, but it likely could just be a simple git patch that you apply on top of the most recent release to change the URL.
Why not just only require the key if you’re connecting to their server and allow you to select your own server without needing to modify and maintain a fork of the firmware?
Because it's an ESP32, they want it to be plug-and-play for those who want that, and they want the battery to last as long as possible.
I think you're not seeing my point. This is in the hardware. It's simple to have a setting that defaults to connecting to the company's server and then have that setting allow for changing the sever target. Why do I need to build firmware to do that?
And, no, it's not acceptable to require forking, regardless of the ease of merging. It still means you won't get critical security updates without manual intervention.
And finally, it's requiring trust. If the company decides to change the license, you are out of luck. And again, the documentation and policies are already lacking, like what happens if your API key is compromised? Do you need to pay for a new one to be generated. These are on your local device.
And no, home assistant doesn't require self-hosting. It requires hardware to put the central system on, but doesn't require an external server for web services. This device is putting the lock inside the hardware you are purchasing. If I purchase hardware, I want it to be mine. Not subject to a license of what you can put on it, even if that license is initially very open. It's my hardware.
Home assistant does sell hardware that is totally open with no license on what software you can put on it. Most people put it on their own hardware. This is totally separate from the cloud service they offer which is for interacting with the sever over the internet and some other stuff. That cloud functionality is totally optional and you aren't required to modify the home assistant code base in order to NOT use the cloud. So it's not at all equivalent.
Even if you don't have external access to Home Assistant, you're still hosting it to your local network by yourself
But were talking about firmware here. My computer also has firmware and an OS. I never have to touch that. Home Assistant is an application that I run on a computer. And I don't have to modify the code in Home Assistant to get it to connect to another device. I just configure it.
I also install Linux on my laptop. Is that self hosting, too? We're not talking about a server or a "host" other than the hardware device itself that lives in the house. If I want the server functionality, sure that's self hosting the server software. Firmware and operating systems are generally not referred to as self-hosting since all devices need those things. Self-hosting refers generally to cloud-based applications, not standalone hardware firmware/OS.
This is a hardware device that is hard coded to connect only to a specific server that you have to pay to access if you want any API functionality. If I want to use my own I have to learn the programming language, figure out how to modify the Firmware, and then maintain a fork of that firmware indefinitely including making sure that there are no automatic updates since that would overwrite the modifications.
I think you have some fundamental confusion.
First, the ESP32 only has firmware because it is a microcontroller and does not have an operating system. It is also primarily a network client that requests data from a service running on a network host. And it also acts as a server on initial boot to host a web UI for configuring WiFi credentials.
Second, Home Assistant is a whole can of worms, but big parts of that are services that run continuously on the machine you install it on that are listening for requests over the network. This is how you access the web UI from a browser. This is how you access the UI from a Home Assistant app on your phone. This is how networked IoT devices send data to Home Assistant. Home Assistant is fairly useless without these services running continuously and doing that makes the machine you run it on what we would colloquially call a "server" or "host".
That's it. That's what self-hosting is. Yes, sometimes you could be also serving data over the internet or have something to do with "the cloud", but that's not necessarily the case, and with the stuff that I host at home, often not.
Your laptop could be a server, depending on what you install on it, but this dichotomy you laid out of "either hosting is only for cloud stuff or, if you have any computer, you are always self-hosting" is just not based in reality. There are fuzzy edges to what it means to be a server, but they're not anywhere close to that fuzzy.
Also, you're making "modify the firmware" into this big monster that it is just not. You don't have to learn a programming language. You don't have to maintain a fork. You're changing one line and running a few commands. They have a tutorial that walks you through it. It's really easy.
On top of that, like I said in another comment responding to you, the need to modify firmware is temporary.
Damn. I would really love one of these, to show off books, show my daily tasks, etc. Really unfortunate its locked down.
Most apps stated in their website if not all are closed source
Their guide still implies that you need to pay a fee to unlock an API key before you can flash a new firmware.
How they plan to enforce that fee to unlock an API key when the firmware is supposedly open source I don't know. When I looked over the source code it looked like it was being written to a log.
The esp32 supports efuses that can be used to require a signed binary to boot. So they could lock their hardware to only work with their binary. Source code wouldn't matter.
Of course if the source is open you can buy and put together your own hardware and then put their code on it.
I'm not advocating what they're doing. Rent seeking is rent seeking even if they need to recoup development costs. I'd rather pay for open hardware and software with no monthly fee.
Honestly, between this and not all the modules being open source I would personally avoid it, seen too many projects openbait and then go "open core".
I agree that the guide is VERY unclear. The documentation here is a bit better, but still bad and mentions a monthly cost for DIY devices instead of a one-time dev-level API key cost.
The gist is that if you want to use their servers and you bought their device, they have an API key built in to the device for their non-dev-level API access, and it's not supported (maybe also against API TOS, but I'm not sure) to extract the API key and use it when you flash custom firmware. Getting the dev-level API key doesn't have this issue, though, because they give that to you when you pay for it.
When modifying the firmware to use on your own server, you don't have to pay them anything because you won't be using their API.
Ah. Can't really complain too much about them wanting people who are putting load on their servers to pay for it. Ideally, that should mean that the end user is not the actual product. Good to see more options joining Inkplate.
Is it possible to self-host a server? Is the server code open source?
Yes to both. The server code is open source under and MIT license as of last night.
IIRC based on the snazzy labs video about it, the answer to both those questions is yes
Looks really neat. I have an old Kindle e-ink screen I scavenged, but I have no clue how to actually interface with it. Being able to hack around with one would be nice.
I think this is designed for that https://github.com/vroland/epdiy
Hey, thanks! That's really cool. I've never gotten a PCB made, but maybe this is a good first time to try it
When does this ship to India?
There's paperd.ink introduced some years back at IndiaFOSS
Thanks for sharing.
Probably never.
Thats something I could be interested in...
Nice!