meshtastic
Flasher and hierarchical config manager
This adds the possibility to flash and configure multiple boards with varying configs.
Configurations can be created in a tree-like structure and each (except the root) inherit values from their parent and can override certain fields.
For each config it can then be specified how many boards shall be given the specific config, an example would be to have a couple of nodes with Bluetooth enabled and several with GPS configured. Setting the LoRa region in the root config is probably a good idea.
Slight modifications on the js package are needed, hence the depency currently points to this fork.
Feedback appreaciated
Exceptional work, I'll work through reviewing this tomorrow. As A start we should focus on merging the fixes in the js library.
Another focus should be to get preview deployments building (broken package lock atm)
Just built this locally to check out and wow! This is very impressive! I have some feedback but it might be a little premature for that, so I'll hold off for now. I'm very excited for what comes out of this though. Great job so far!
@rcarteraz happy for any feedback
Sounds good. I'm out right now but I'll post when I get back this evening.
First, I really like this can't compliment the work that's been done enough, because it's fantastic! I think it's a wonderful update that will be immensely useful, but maybe with some changes first. Purely thinking about the user experience here, which is why I bring these items up. Okay, so a couple items I can think of.
-
This new version opens straight to the combined flasher/configure screen. I think this would be very overwhelming to newer users. We should keep the initial connection flow we currently have and make this an option on the sidebar. Either of these two areas below. Another reason for this would be the fact that the flasher (at least as far as I can tell) is still for ESP32 devices only (which is also something we should denote). This way (assuming I'm correct) we don't lead users to believe the can use it with their device when they cannot.
-
Additionally, I think we should create a toggle and have two views here. Maybe "Standard" and "Advanced". Standard should be just the flashing elements. Again, the reason for this is it can be overwhelming to some users, who are unsure if they need to select any of those options or not. Plus if they're just updating the firmware, this keeps them from making any changes to their current setup. For those that want to flash/configure multiple devices they can flip the toggle and easily do so. And for the rest they can configure as they have.
- Might be a good idea to remove auto-detect. It's a little wonky and likely will cause more issues than not. We should just have the users select their device manually. Unless we can improve this somehow.
- There doesn't seem to be an option to just update the firmware. Even if you do not toggle "Force Wipe and Reinstall" it seems to do exactly that still. At least in the testing that I've done so far.
I think that's all I have for now. It's late so I'll leave it at this and if anything else comes to mind, I'll be sure to add it.
- Might be a good idea to remove auto-detect. It's a little wonky and likely will cause more issues than not. We should just have the users select their device manually. Unless we can improve this somehow.
Auto-detect for updates should be doable if a want-config is called and we get the HWModel from the DeviceMetadata payload.
Auto detect is pretty much impossible if the device does not have Meshtastic on it yet so a manual path is always needed devices with Meshtastic can be identified as @thebentern stated.
Is there a risk to any existing functionality by merging this? Seems like great features separate from the existing functionally that we can patch as we find stuff. The pull is starting to get stale which is never any fun for a large pull.