Making this work without a first-party backend would require a way to regularly change configuration data on the embedded device by pairing it with the mobile app. Bluetooth or local wifi access point. That's do-able, but unless you're Apple, it's hard to make that a seamless experience.
I went for the mandatory first-party option because it is important to me to build a device that is super reliable. Nobody wants to debug the bluetooth connection with a calendar. Running the server is cheap enough that I can keep it running for a decade or more, even after I stop selling the last device.
Still, the comments in this post have convinced me that offering this as a fallback option may be a good idea, to address the understandable concerns about obsolescence.
Seconded. If this had a robust-simple option for how i can use this purely locally, i'd get one instantly. "Push JSON to this local web server" sort of simplicity, or w/e.
You're right though, it would need to "just work".
edit: Also battery options for wall mounting would be amazing too. I'm actually super interested in this project, but the local-first API is my primary entry point.
I like the product and can see a couple of nice uses for it. For instance I have a grafana dashboard to track my solar setup. Home assistant stuff comes to mind. Maybe some contextual stuff like showing a 5pm ‘time to get off your ass’ message.
But I do agree that being able to do all that stuff without relying on someone else’s server would be more or less a requirement for me. I’d be fine with rendering html on some other machine if that’s the problem here.
Without a first-party backend service, the smart screens would need to store configuration data (e.g. which app is currently active, where to reach the render endpoint) directly on the device. Every time you wanted to change that data, for example to change which app is active on the device, you would need to pair to it with bluetooth or some other means.
Now that I think about it, I actually like the idea of offering this as a fallback option. Hmm... but I don't want to over-promise anything.
But as long as the backend is available, handling configuration changes on the backend is simply a much better user experience. This is why I chose this option as the initial way to go.
I hope this makes some sense, I am happy to answer further questions.
5 comments
[ 2.2 ms ] story [ 18.3 ms ] threadI went for the mandatory first-party option because it is important to me to build a device that is super reliable. Nobody wants to debug the bluetooth connection with a calendar. Running the server is cheap enough that I can keep it running for a decade or more, even after I stop selling the last device.
Still, the comments in this post have convinced me that offering this as a fallback option may be a good idea, to address the understandable concerns about obsolescence.
You're right though, it would need to "just work".
edit: Also battery options for wall mounting would be amazing too. I'm actually super interested in this project, but the local-first API is my primary entry point.
But I do agree that being able to do all that stuff without relying on someone else’s server would be more or less a requirement for me. I’d be fine with rendering html on some other machine if that’s the problem here.
Now that I think about it, I actually like the idea of offering this as a fallback option. Hmm... but I don't want to over-promise anything.
But as long as the backend is available, handling configuration changes on the backend is simply a much better user experience. This is why I chose this option as the initial way to go.
I hope this makes some sense, I am happy to answer further questions.