Make firmware updating easier (automated)

[hicksticks2001]

This project is very active and I expect as more wards use j-tech, there will be even more desire to add features that simplified the life cycle of j-tech devices.

1) would be great if the firmware knew of the source location of where you publish it on GitHub so that it can check for updates and we just click “yes” or “update” when it detects updates

2) would be nice to be able to turn on auto updates where if enabled it simply checks, applies, and restarts automatically after a new firmware is applied

(This is also a feature I can see j-tech wanting to bring into their mainline of firmware as long as the source url is configurable)

[bretep]

Absolutely 100% agree. A few issues I'm trying to design around.

1. There is only 24mb total disk space on the device. My firmware is 9.9MB, and the firmware requires double the space when downloading, verifying it's a good binary, and then extracting. This leaves me only two more MB.

2. Scheduling. I don't want an auto update to happen during a webcast, and I want to make sure the end-user can configure when it happens.

3. Rollbacks. If a bad firmware is released, I need to ensure a safe rollback can happen (or fix forward).

I have 8 of these devices I have to keep up to date. I feel the pain.

[hicksticks2001]

Just as an idea, you can have it check the webcast auto configuration for if there is a current broadcast, and if the xml doesn’t contain a stream then you can do an auto update?

Also, if space is an issue are there features we can remove that we would never need for church purposes to save space?

[bretep]

Scheduling

I could, but I'd like to give the end-user the ability to control updates. If I publish one on Saturday night that breaks something, I don't want to have an emergency on Sunday. So giving the user the ability to schedule when updates are allowed would be best.

Size

Fo everything that I have developed, I've removed everything I can think of during compiling like debug information (which I dislike doing). The bulk of the space is taken up by kernel modules and the j-tech box binary, which I don't have access to source code to do any optimizations there. While I could remove kernel modules, I looked at the strings in the box binary, and it depends on those kernel modules existing, which may introduce instability.

If I had access to the development files for the OS, I might be able to link some of my libraries and not bundle them statically, but that depends if they are included with the OS distribution.

Implementation & timeline

I plan to implement this feature, which may include downloading and expanding in memory, but I have to balance my development time with other priorities I have. :) So I can't commit to a time that it would be done. However, you can see that I made this firmware to optimize my time, and auto-updating helps out my goal to do so. Which means it ranks high on my list of things I'd like to get done.

[hicksticks2001]

You're reasoning makes sense - thank you for taking the time to respond. On an unrelated note - we did two successful broadcasts today with a J-Tech running your firmware and were able to switch between ward broadcasts by power cycling the J-Tech box.

I have more J-Tech boxes ordered and on their way to me as our Stake roles this out to our other buildings/wards.

[bretep]

Excellent! A power cycle is not required to switch to the next meeting, as my firmware checks for what broadcast it's supposed to be publishing to every 10 seconds.

Did you mean you powered the j-tech off at the close of the meeting? If so, that's what we do and then the next ward power's the j-tech box back on.

There is a caveat on picking up a new broadcast when meetings using the same j-tech device are spaced 30 minutes apart. For example: 1st meeting ends at 10:00 am and 2nd meeting starts at 10:30 am. Currently, the church has a 15-minute post buffer and will not publish the 2nd meeting until that has completed. So the j-tech will pick up the new meeting at approximately 10:15 am.

[hicksticks2001]

@bretep - we are currently using the powering off the J-Tech for 2 purposes 1) To not broadcast the Sacrament Ordinance 2) to switch to the next broadcast

I didn't realize your firmware did this check. All of our broadcasts are at 9am and 11am with a scheduled duration of 1 hour. You can see our schedule at paysonworship.com So in my scenario - when would you expect the firmware to auto switch over if we didn't interfere with the schedule via the WebCast Event Manager or power cycle the J-Tech?

[bretep]

In your scenario, your j-tech will automatically switch to the next broadcast at around 10:15 am (as long as the device is powered on).

The 11:00 am pre-buffer starts at 10:00 am. The 10:00 am post-buffer stops at 10:15 am

The church updates the auto-config after the first meeting post buffer is complete, which is at 10:15 am and the j-tech will get the new config within 10 seconds of the church updating the auto-config

[Jason-Kou]

This is Jason from J-Tech Digital. We will try our best to cooperate with Bret to build some functions into the 'Box' binary file. Thank you for Bret's excellent effort on this project.