Geektoolkit
patreon
Spec Preview for Major neworking changes to Dynaframe
🕑 Added 2022-12-30 09:21:21 +0000 UTCTLDR; Dynaframes networking is taking a major change which will require devices to have a keyboard hooked up when first setting them up (unless they're plugged into a network jack). If this is horrible or going to break your scenarios please provide feedback int he comments. But also, let me please explain why....
The team holds a high bar for the software and what we want it to achieve. The problem is that the top issue is wifi connectivity. Other countries are on different frequencies, there's bugs in the third party software we're relying on, and other issues. And when someone can't connect to the wifi access point, that means that the very first thing we've delivered to them as a team is...well...a headache. That's terrible, we have to do better.
I thought we could fix all the bugs, but while we try, we have user after user reporting issues with setup and that's painful. For some of you it's worked great. but even on our team we've had issues where it's not worked, and that's frustrating.
Now there's also a boatload of feature requests that we simply need to do asap. Stuff like 'setting date/time' from the web page. Setting regions. Allowing the setting of a password and a host name.
So the spec linked above is the rough draft of the details and the problem statement which I promised to share. This was discussed in a meeting today, and will be reviewed by the team. I'd like those of you that have given feedback about scenarios such as the gallery scenario, or the 'gifting to a loved one' scenario, to take a look and let me know if this will solve those for you. While we have some prototype work going on for this, my goal is to lock down on the spec in the next week or so so I can work to deliver something in January, either a full implementation or enough to get users unblocked.
It will require a keyboard on the device, but in exchange we hope to increase functionality and reliability for connections well beyond what it is today. I also would love to have the scenario of taking it to a trade show, using it in a gallery, or gifting to a loved one to be rock solid.
Thanks for taking the time to look at it. If it's terrible or if you have feedback please feel free to comment below, or if you have questions. This is a feature driven by you, the Patrons, and I'm proud to be able to deliver these scenarios to you!
Thanks,
Joe
Geektoolkit
Comments
I just joined your Patreon, after having loosely followed the project on GitHub, and I must compliment the onboarding & WiFi setup with the adhoc system in July 2023! I got a Pi4 to make sure it ran smooth, and when ordering that, I saw a $17 480x320 color touchscreen, thinking that might save me should something go wrong. Perhaps you've discussed a touchscreen elsewhere, but I'm hoping I can use it to make DF controllable from the Pi itself, no phone required, not optical sensor. Anyway, just an idea to add touchscreen for a future update! Carry on...
Joe Farro
Excellent feedback, points and ideas. We have driven some fixes into comitup which is what we relied on. Its a very 'heavy' solution for the amount of work it takes us to even leverage it. Also it's reliance on taking out the network stack from Raspbian makes it a bit cumbersome for power users who would benefit greatly from having access to the stack, so even if we do get everything fixed (and we have improved it to an extent) it's still brutal. I'm going to take a week and do some investigations to come up with some options. There's things like bluetooth pairing to send the wifi creds over. Also I'm looking at just putting in my own 'ad hoc wifi' setup into the frame so that we can emulate what comitup does, but in a much better way. I figure I'll take some time and see what is possible. Ideally we have both options...we have a first run with a GUI for setup, but we also have a wifi access point sitting out there...which if connected to takes you direclty to our web UI. That way you can connect ad/hoc and control it, and then in that UI we can expose a way to go form adhoc (access point) to infrastructure (which would connect to wifi). We as a team want that as well. I'll see what I can do over the week and report back here. I can say with some glee I successfully put the wireless chip in ad hoc mode today and connected with my phone, and the frame got an IP address. But my phone couldn't see the web page...so I'm not sure if I'm close or not. :)
I would hate to lose the WiFi setup option. It's been a huge benefit to my use of Dynaframe and makes it so easy to take a completed frame to another location and get it on the local network without any fuss. I took a completed frame to a holiday gathering a few weekends ago and it was so simple to boot it up and get it on the network. It's one of those things that makes Dynaframe really feel like a commercial solution. I understand your point that when this system fails, it can cause headaches for your users and those who support them. That's a completely fair and valid concern. I wonder though if it's solving more headaches than it's causing? Is the project that underpins this feature beyond fixing, or would it benefit both projects to contribute bug fixes? Would you be open to considering a branch that has automated WiFi Setup and another that has a keyboard-based configuration? Or perhaps there's a way to use a semaphore file in the boot partition or on a USB drive at first boot to indicate whether automated WiFi setup should be attempted, or if a keyboard-based workflow should be used instead? I'd hate to have to lug a keyboard everywhere when I didn't have to before. In any case, thanks for continued updates! I'm looking forward to seeing Dynaframe grow in 2023!
