Create wled-tools #4625
Create wled-tools #4625
Conversation
Per discussion, add a discover-fueled tool to update/backup wled devices in the local network.
WalkthroughA new Bash script named Changes
Tip ⚡💬 Agentic Chat (Pro Plan, General Availability)
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (5)
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (6)
tools/wled-tools.sh (6)
3-9: Unused Color Variable Defined
TheGREENvariable is defined but never used in the script. Consider removing it or utilizing it for consistency with the other color definitions.🧰 Tools
🪛 Shellcheck (0.10.0)
[warning] 4-4: GREEN appears unused. Verify use (or export if used externally).
(SC2034)
27-47: Generic cURL Handler is Functional
Thecurl_handlerfunction encapsulates HTTP request error handling well. One minor point: ensure that the command passed to this function does not introduce word-splitting issues. Consider validating or sanitizing$commandif user input could ever be involved.
71-87: Device Discovery Function is Effective
Thediscover_devicesfunction leveragesavahi-browseand processes its output correctly. If you wish to enhance robustness, consider outputting discovered device entries as newline-separated values instead of a space‐delimited string (this can help avoid potential parsing issues when hostname fields contain spaces).
89-113: Backup Function – Quotation Issue in cURL Command Strings
In thebackup_onefunction, the assignments on lines 105 and 106 trigger shellcheck warnings because inner quotes are not properly escaped. This may lead to unexpected behavior when the URLs or destination paths contain spaces.
Consider applying the following diff to fix the quoting:- local curl_command_cfg="curl -s "$cfg_url" -o "$cfg_dest.tmp"" - local curl_command_presets="curl -s "$presets_url" -o "$presets_dest.tmp"" + local curl_command_cfg="curl -s \"$cfg_url\" -o \"$cfg_dest.tmp\"" + local curl_command_presets="curl -s \"$presets_url\" -o \"$presets_dest.tmp\""🧰 Tools
🪛 Shellcheck (0.10.0)
[warning] 105-105: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
[warning] 106-106: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
115-128: Firmware Update Function – Quotation in cURL Command Needs Correction
On line 125 inupdate_one, the command string is not properly quoted, which may lead to issues with files or URLs containing spaces. Applying proper escaping will make the command robust. For example:- local curl_command="curl -s -X POST -F "file=@$firmware" "$url"" + local curl_command="curl -s -X POST -F \"file=@$firmware\" \"$url\""🧰 Tools
🪛 Shellcheck (0.10.0)
[warning] 125-125: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
181-242: Command Execution Block Appears Consistent
The switch-case block executing the chosen command (discover,backup, orupdate) is logically structured and handles errors (e.g., missing targets) appropriately. Ensure that the assumptions (e.g., defaulting to port 80 for a target) are documented if they are intended design decisions.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
tools/wled-tools.sh(1 hunks)
🧰 Additional context used
🪛 Shellcheck (0.10.0)
tools/wled-tools.sh
[warning] 4-4: GREEN appears unused. Verify use (or export if used externally).
(SC2034)
[warning] 105-105: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
[warning] 106-106: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
[warning] 125-125: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
🔇 Additional comments (1)
tools/wled-tools.sh (1)
11-25: Logging Function Implementation Looks Good
Thelogfunction correctly handles conditional terminal output based on thequietflag and whether the output is a terminal.
tools/wled-tools.sh
Outdated
| while [[ $# -gt 0 ]]; do | ||
| case "$1" in | ||
| -h|--help) | ||
| show_help | ||
| exit 0 | ||
| ;; | ||
| -t|--target) | ||
| target="$2" | ||
| shift 2 | ||
| ;; | ||
| -D|--discover) | ||
| discover=true | ||
| shift | ||
| ;; | ||
| -d|--directory) | ||
| backup_dir="$2" | ||
| shift 2 | ||
| ;; | ||
| -f|--firmware) | ||
| firmware_file="$2" | ||
| shift 2 | ||
| ;; | ||
| -q|--quiet) | ||
| quiet=true | ||
| shift | ||
| ;; | ||
| backup|update|discover) | ||
| command="$1" | ||
| shift | ||
| ;; | ||
| *) | ||
| log "ERROR" "$RED" "Unknown argument: $1" | ||
| exit 1 | ||
| ;; | ||
| esac |
There was a problem hiding this comment.
💡 Verification agent
❓ Verification inconclusive
Missing Verbose Option Handling in Command-Line Arguments
While the help message (show_help) describes a -v/--verbose option, there is no case handling for it in the argument processing loop. If verbose output is intended, add an option block to set a verbose variable and use it accordingly in your functions (for example, to control additional debug output).
Missing Verbose Option Handling in Command-Line Arguments
The help message clearly references a -v/--verbose option to enable verbose output; however, the current argument parser in tools/wled-tools.sh (lines 143-177) lacks any handling for this flag. To align the implementation with the documentation, please add a case for -v|--verbose that sets a verbose variable (e.g., to true) and then shifts the arguments. For instance:
-v|--verbose)
verbose=true
shift
;;This update will ensure that verbose mode can be correctly activated as documented.
There was a problem hiding this comment.
Is CodeRabbit correct about this?
There was a problem hiding this comment.
@netmindz Yes, CodeRabbit is correct about this issue. Looking at the script, there's a -v, --verbose option described in the help text (around line 55), but there's no corresponding case handler in the argument processing section (lines 143-177).
All the other options mentioned in the help text have proper handlers, but the verbose option is missing its implementation. Adding the suggested code would properly implement the verbose flag:
-v|--verbose)
verbose=true
shift
;;Additionally, you'd need to initialize the verbose variable at the top of the script where the other option variables are defined (around line 133-137).
There was a problem hiding this comment.
CodeRabbit you seem pretty sure... 😄 However someone else needs to verify if you are indeed correct. And I'm not saying you are not.
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
tools/wled-tools.sh (1)
142-177: 🛠️ Refactor suggestionMissing Verbose Option Handling
The PR objectives and help text documentation indicate support for a verbose flag (-v/--verbose), yet no corresponding case exists in the argument parsing block. To enable verbose logging, add handling for this flag (e.g., set a global variableverbose=true) and update the help text to list the verbose option.Proposed diff for the argument parsing (suggest inserting after the
-f|--firmwarecase and before-q|--quiet):- -f|--firmware) - firmware_file="$2" - shift 2 - ;; + -f|--firmware) + firmware_file="$2" + shift 2 + ;; + -v|--verbose) + verbose=true + shift + ;;Proposed diff for updating the help message (inside the heredoc in
show_help):-f, --firmware <File> Specify the firmware file for updating devices. + -v, --verbose Enable verbose output for debugging. -q, --quiet Suppress logging output (also makes discover output hostnames only).
🧹 Nitpick comments (4)
tools/wled-tools.sh (4)
4-8: Unused Variable Warning: GREEN
The variableGREENis defined at the top but is never referenced in the script. If you plan to use it in future logging or other features, consider adding an inline comment for clarity; otherwise, removing it could help clean up the code.🧰 Tools
🪛 Shellcheck (0.10.0)
[warning] 4-4: GREEN appears unused. Verify use (or export if used externally).
(SC2034)
104-105: Fix Quoting in Curl Command Construction for Backup
The curl command strings in thebackup_onefunction use inner quotes without escaping, which may lead to unexpected behavior or shellcheck warnings. Using escaped quotes will ensure the URL and destination paths are correctly interpreted.- local curl_command_cfg="curl -s "$cfg_url" -o "$cfg_dest.tmp"" - local curl_command_presets="curl -s "$presets_url" -o "$presets_dest.tmp"" + local curl_command_cfg="curl -s \"$cfg_url\" -o \"$cfg_dest.tmp\"" + local curl_command_presets="curl -s \"$presets_url\" -o \"$presets_dest.tmp\""🧰 Tools
🪛 Shellcheck (0.10.0)
[warning] 104-104: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
[warning] 105-105: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
124-124: Fix Quoting in Curl Command for Firmware Update
The curl command in theupdate_onefunction is also affected by unescaped inner quotes. Escaping these quotes correctly will fix potential issues with command interpretation.- local curl_command="curl -s -X POST -F "file=@$firmware" "$url"" + local curl_command="curl -s -X POST -F \"file=@$firmware\" \"$url\""🧰 Tools
🪛 Shellcheck (0.10.0)
[warning] 124-124: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
107-111: Enhance Backup Error Handling
In thebackup_onefunction, both curl calls are executed without checking their exit statuses. To prevent partial backups (e.g., renaming temporary files even if one download fails), consider verifying that eachcurl_handlercall succeeds before moving the temporary files. For example:if ! curl_handler "$curl_command_cfg" "$hostname"; then log "ERROR" "$RED" "Failed to backup config for $hostname." return 1 fi if ! curl_handler "$curl_command_presets" "$hostname"; then log "ERROR" "$RED" "Failed to backup presets for $hostname." return 1 fi mv "$cfg_dest.tmp" "$cfg_dest" mv "$presets_dest.tmp" "$presets_dest"This additional check will help ensure data integrity during the backup process.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
tools/wled-tools.sh(1 hunks)
🧰 Additional context used
🪛 Shellcheck (0.10.0)
tools/wled-tools.sh
[warning] 4-4: GREEN appears unused. Verify use (or export if used externally).
(SC2034)
[warning] 104-104: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
[warning] 105-105: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
[warning] 124-124: The surrounding quotes actually unquote this. Remove or escape them.
(SC2027)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: wled_build / Build Environments (usermods)
- GitHub Check: wled_build / Build Environments (esp32s3dev_8MB_opi)
There was a problem hiding this comment.
Actionable comments posted: 3
🔭 Outside diff range comments (1)
tools/wled-tools (1)
1-241: 🛠️ Refactor suggestionConsider adding verbose mode for additional debugging information.
The script defines a
-vor--verboseoption in the help text, but doesn't implement it in the code. Consider adding a verbose mode that provides additional details during execution:# Command-line arguments processing command="" target="" discover=false quiet=false +verbose=false backup_dir="./" firmware_file="" # ... (in the argument processing section) + -v|--verbose) + verbose=true + shift + ;; # ... (modify the log function) log() { local category="$1" local color="$2" local text="$3" + local level="$4" + # Skip debug messages unless verbose mode is enabled + if [ "$level" = "DEBUG" ] && [ "$verbose" != true ]; then + return + fi if [ "$quiet" = true ]; then return fi # ... (rest of the function) } # ... (then use it for debug logging) +if [ "$verbose" = true ]; then + log "DEBUG" "$BLUE" "Using target: $target" "DEBUG" +fi
🧹 Nitpick comments (4)
tools/wled-tools (4)
1-9: The script should have executable permissions.Make sure to add executable permissions to the script file:
chmod +x tools/wled-toolsAdditionally, consider renaming the file to match its mention in the PR as "wled-tools.sh" for consistency.
27-47: Consider adding more robust error handling in the curl_handler function.The curl_handler function has good error handling, but could be improved:
- Add error handling for malformed URLs
- Consider capturing and logging the actual response body on error
- Add timeout handling to prevent hanging on unresponsive devices
curl_handler() { local command="$1" local hostname="$2" + local timeout=10 - response=$($command -w "%{http_code}" -o /dev/null) + response=$($command -m $timeout -w "%{http_code}" -o /tmp/curl_error.$$) curl_exit_code=$? if [ "$response" -ge 200 ] && [ "$response" -lt 300 ]; then + rm -f /tmp/curl_error.$$ return 0 elif [ $curl_exit_code -ne 0 ]; then - log "ERROR" "$RED" "Connection error during request to $hostname (curl exit code: $curl_exit_code)." + log "ERROR" "$RED" "Connection error during request to $hostname (curl exit code: $curl_exit_code). $(cat /tmp/curl_error.$$)" + rm -f /tmp/curl_error.$$ return 1 elif [ "$response" -ge 400 ]; then - log "ERROR" "$RED" "Server error during request to $hostname (HTTP status code: $response)." + log "ERROR" "$RED" "Server error during request to $hostname (HTTP status code: $response). $(cat /tmp/curl_error.$$)" + rm -f /tmp/curl_error.$$ return 2 else - log "ERROR" "$RED" "Unexpected response from $hostname (HTTP status code: $response)." + log "ERROR" "$RED" "Unexpected response from $hostname (HTTP status code: $response). $(cat /tmp/curl_error.$$)" + rm -f /tmp/curl_error.$$ return 3 fi }
114-127: Improve update_one function with better feedback and error handling.The update function should provide better feedback to the user about the update progress and result:
update_one() { local hostname="$1" local address="$2" local port="$3" local firmware="$4" log "INFO" "$YELLOW" "Starting firmware update for device: $hostname ($address:$port)" local url="http://$address:$port/update" - local curl_command="curl -s -X POST -F "file=@$firmware" "$url"" + local curl_command="curl -s -X POST -F "file=@$firmware" "$url" -o /tmp/update_result.$$" - curl_handler "$curl_command" "$hostname" + if curl_handler "$curl_command" "$hostname"; then + log "INFO" "$GREEN" "Firmware update initiated successfully for $hostname" + log "INFO" "$BLUE" "Device may reboot and be temporarily unavailable" + return 0 + else + log "ERROR" "$RED" "Failed to update firmware for $hostname" + return 1 + fi }
197-211: Add validation for the backup directory in the backup command.The script should verify that the backup directory is writable:
backup) if [ -n "$target" ]; then + # Check if backup directory is writable + if ! [ -d "$backup_dir" ] && ! mkdir -p "$backup_dir" 2>/dev/null; then + log "ERROR" "$RED" "Backup directory '$backup_dir' doesn't exist and cannot be created" + exit 1 + fi + if ! [ -w "$backup_dir" ]; then + log "ERROR" "$RED" "Backup directory '$backup_dir' is not writable" + exit 1 + fi # Assume target is both the hostname and address, with port 80 backup_one "$target" "$target" "80" elif [ "$discover" = true ]; then
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
tools/wled-tools(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (4)
- GitHub Check: wled_build / Build Environments (esp32s3_4M_qspi)
- GitHub Check: wled_build / Build Environments (usermods)
- GitHub Check: wled_build / Build Environments (esp32s3dev_16MB_opi)
- GitHub Check: wled_build / Build Environments (lolin_s2_mini)
🔇 Additional comments (3)
tools/wled-tools (3)
11-25: Good logging implementation with color support and terminal detection.The logging function properly handles colored output for terminals and plain text for non-terminal output. It also respects the quiet flag.
215-219: Good validation of firmware file existence.The check that ensures the firmware file exists before proceeding with the update is a good practice.
1-241: Overall this is a well-structured and useful utility script.The script provides valuable functionality for managing WLED devices. It has good error handling, clear help text, and a well-designed command structure. With the suggested improvements to robustness and user feedback, it will be an even more valuable tool for WLED users.
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (4)
tools/wled-tools (4)
1-2: Add file permissions to make the script executable.The script should have executable permissions. After adding the file to the repository, you should run:
chmod +x tools/wled-tools
1-2: Consider adding version information to the script.Including version information would help track changes and compatibility.
#!/bin/bash +# WLED Tools v1.0.0 +# A utility for managing WLED devices in a local network +# https://github.com./wled/WLED
134-136: Add a Content-Type header to the firmware update request.For better compatibility, explicitly set the Content-Type header for the multipart form data.
local url="http://$address:$port/update" -local curl_command="curl -s -X POST -F "file=@$firmware" "$url"" +local curl_command="curl -s -X POST -H 'Content-Type: multipart/form-data' -F "file=@$firmware" "$url""
49-68: Add examples to the help section.Including usage examples in the help text would make it easier for users to understand how to use the tool.
show_help() { cat << EOF Usage: wled-tools.sh [OPTIONS] COMMAND [ARGS...] Options: -h, --help Show this help message and exit. -t, --target <IP/Host> Specify a single WLED device by IP address or hostname. -D, --discover Discover multiple WLED devices using mDNS. -d, --directory <Path> Specify a directory for saving backups (default: working directory). -f, --firmware <File> Specify the firmware file for updating devices. -q, --quiet Suppress logging output (also makes discover output hostnames only). Commands: backup Backup the current state of a WLED device or multiple discovered devices. update Update the firmware of a WLED device or multiple discovered devices. discover Discover WLED devices using mDNS and list their IP addresses and names. +Examples: + # Discover all WLED devices on the network + ./wled-tools.sh discover + + # Backup a specific WLED device + ./wled-tools.sh -t 192.168.1.100 backup + + # Backup all discovered WLED devices to a specific directory + ./wled-tools.sh -D -d /path/to/backups backup + + # Update firmware on all discovered WLED devices + ./wled-tools.sh -D -f /path/to/firmware.bin update EOF }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
tools/wled-tools(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: wled_build / Build Environments (usermods)
🔇 Additional comments (3)
tools/wled-tools (3)
71-86: Fix hostname parsing to handle spaces in device names.The current parsing method assumes space-delimited output, but device hostnames might contain spaces, which would break the parsing logic.
Apply this fix to handle delimitation properly:
- mapfile -t raw_devices < <(avahi-browse _wled._tcp --terminate -r -p | awk -F';' '/^=/ {print $7, $8, $9}') + # Use a unique delimiter unlikely to appear in hostnames (unit separator character) + mapfile -t raw_devices < <(avahi-browse _wled._tcp --terminate -r -p | awk -F';' '/^=/ {print $7"\x1F"$8"\x1F"$9}') local devices_array=() for device in "${raw_devices[@]}"; do - read -r hostname address port <<< "$device" + IFS=$'\x1F' read -r hostname address port <<< "$device" devices_array+=("$hostname" "$address" "$port") done
107-117: Excellent implementation of error handling in the backup function.The code properly checks the curl operation result and handles errors well. It correctly removes temporary files on failure and provides appropriate error messages.
160-163: Well-implemented parameter validation.The validation of command-line parameters that require arguments is properly implemented as suggested in a previous review.
Also applies to: 172-175, 180-183
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com.>
|
Thank you. |
|
I suppose. I have no idea presently what Mac might require or look like. I can likely get ChatGPT to make a batch/powershell script for windows with similar functionality and verify it works.
Mike.
Sent from Outlook for iOS<https://aka.ms/o0ukef>
…________________________________
From: Blaž Kristan ***@***.***>
Sent: Sunday, April 6, 2025 10:25:16 AM
To: wled/WLED ***@***.***>
Cc: Michael Bisbjerg ***@***.***>; Mention ***@***.***>
Subject: Re: [wled/WLED] Create wled-tools.sh (PR #4625)
Thank you.
Would it be possible to add counterparts for Windows and Mac computers?
Some of the Linux tools are unavailable on mac even with Homebrew.
—
Reply to this email directly, view it on GitHub<#4625 (comment)>, or unsubscribe<https://github.com./notifications/unsubscribe-auth/AAH2YJY2DLYY3YH7ZRYHBDL2YDQGZAVCNFSM6AAAAAB2BLJYCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOBRGMYDGOJXGI>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
[blazoncek]blazoncek left a comment (wled/WLED#4625)<#4625 (comment)>
Thank you.
Would it be possible to add counterparts for Windows and Mac computers?
Some of the Linux tools are unavailable on mac even with Homebrew.
—
Reply to this email directly, view it on GitHub<#4625 (comment)>, or unsubscribe<https://github.com./notifications/unsubscribe-auth/AAH2YJY2DLYY3YH7ZRYHBDL2YDQGZAVCNFSM6AAAAAB2BLJYCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOBRGMYDGOJXGI>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
I will be able to lend support/testing on mac. |
|
The initial implementation had a verbose, but it didn’t make sense, so I removed it. If the script still has verbose, I’ve made a mistake.
Coderabbit was a bit confusing as I made a few pushes in a short timeframe, so it made mixed responses.
Sent from Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: coderabbitai[bot] ***@***.***>
Sent: Sunday, April 6, 2025 11:31:10 AM
To: wled/WLED ***@***.***>
Cc: Michael Bisbjerg ***@***.***>; Mention ***@***.***>
Subject: Re: [wled/WLED] Create wled-tools.sh (PR #4625)
@coderabbitai[bot] commented on this pull request.
________________________________
In tools/wled-tools.sh<#4625 (comment)>:
+while [[ $# -gt 0 ]]; do
+ case "$1" in
+ -h|--help)
+ show_help
+ exit 0
+ ;;
+ -t|--target)
+ target="$2"
+ shift 2
+ ;;
+ -D|--discover)
+ discover=true
+ shift
+ ;;
+ -d|--directory)
+ backup_dir="$2"
+ shift 2
+ ;;
+ -f|--firmware)
+ firmware_file="$2"
+ shift 2
+ ;;
+ -q|--quiet)
+ quiet=true
+ shift
+ ;;
+ backup|update|discover)
+ command="$1"
+ shift
+ ;;
+ *)
+ log "ERROR" "$RED" "Unknown argument: $1"
+ exit 1
+ ;;
+ esac
@netmindz<https://github.com./netmindz> Yes, CodeRabbit is correct about this issue. Looking at the script, there's a -v, --verbose option described in the help text (around line 55), but there's no corresponding case handler in the argument processing section (lines 143-177).
All the other options mentioned in the help text have proper handlers, but the verbose option is missing its implementation. Adding the suggested code would properly implement the verbose flag:
…-v|--verbose)
verbose=true
shift
;;
Additionally, you'd need to initialize the verbose variable at the top of the script where the other option variables are defined (around line 133-137).
—
Reply to this email directly, view it on GitHub<#4625 (comment)>, or unsubscribe<https://github.com./notifications/unsubscribe-auth/AAH2YJ5YMIFDVCOFOI6AVCD2YDX55AVCNFSM6AAAAAB2BLJYCOVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDONBVGA4DQOBYGQ>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 77 🏁 Script executed: Length of output: 69658 🏁 Script executed: Length of output: 23 🏁 Script executed: Length of output: 20322 🏁 Script executed: Length of output: 8561 @LordMike You're absolutely right. I've checked the current version of the wled-tools.sh script, and there's no mention of a verbose flag in either the help text or the argument processing section. The script is consistent and doesn't contain any The previous comment was incorrect, and I apologize for the confusion. This might have happened due to the multiple pushes in a short timeframe as you mentioned. |
So, I looked into it.
So I might not be able to make a windows port, but I can do mac. If I were to do a windows port, I'd probably say, make a compiled binary for each platform instead. They're likely easier to make and will work more consistently on all platforms. But I don't think I have the time for that at present. I'll make adjustments for mac. Mac does have "dns-sd" which is an mDNS (Bonjour) client, but it does not expose ip addresses as I understand it. Now, I could either:
I could resolve hostnames (curl does this internally, so no need), but the issue as I see it is that we then rely on local name resolution working at the users location. If dns-sd reports back "wled-01.local", but for whatever reason its not possible to resolve that address (ie. The script already checks if avahi-browse is available and reports if not. It should work on mac. |
|
Sample: You need to press Ctrl-C to end dns-sd. |
|
Hi there, I just made also a tool to discover nodes on the network, see https://github.com./ewowi/ESP32Instances. So my tool uses node.js to create a server which receives (WLED) UDP messages and provides a html page to display the instance name and the ip as url to jump directly to the instance. No support for backup and flash (yet). I personally think node.js and html / js is a more versatile and portable toolset then bash scripts but thats personal preference I guess. I think this tool, my tool and also WLED-Native by @Moustachauve all have a certain overlap to ultimately do all the same. I am currently leaning towards tools which are as user-friendly as possible so not only it-nerds can work with it but any end-user. WLED-native currently comes closest to that IMO. In this respect I am also investigating Bluetooth support, as that makes it really easy to make a WLED device manageable by end-users (like done in the Glorb/SNRGY app. Another thought: Maybe it is a good idea to create a separate repo for WLED/ESP32 tools e.g. wled/WLED-tools where all tools can be collected. This keeps the wled/WLED repo a bit cleaner, as there is already so much in there. So far my thoughts, I have always very great ideas but to realise all of them is another thing ;-) So this bash tool is straight forward and runs, so go for it ! @coderabbitai, what do you think? Maybe you can make the universal tool which does everything on every platform? |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain@ewowi Thanks for sharing your feedback and your ESP32Instances project! After examining the The current bash script provides powerful command-line functionality for discovering, backing up, and updating WLED devices, which works well for Linux environments and likely Mac with some adjustments. Your node.js approach with ESP32Instances offers better cross-platform compatibility with a user-friendly web interface, though focused primarily on discovery. Regarding creating a universal tool, I think there are several approaches worth considering:
Each approach has its own audience - CLI tools for power users and automation, and GUI tools for broader accessibility. Rather than one universal solution replacing all others, perhaps a complementary ecosystem with shared core libraries would be most beneficial. What are your thoughts on collaborating on core functionality while maintaining different interfaces for different user needs? 🏁 Script executed: Length of output: 8662 @ewowi Thanks for sharing your ESP32Instances project and your thoughts on the WLED tools ecosystem! After examining the The current bash script provides powerful command-line capabilities for device discovery, backup, and firmware updates, while your Node.js approach offers better cross-platform compatibility with a user-friendly web interface. WLED-Native seems to focus on end-user experience, and the Bluetooth approach you're investigating could make device management even more accessible. Regarding creating a universal tool, here are some thoughts:
Rather than one tool replacing all others, perhaps the most practical approach is a "family" of tools that share core components but are optimized for different use cases: graph TD
A[Core Library] --> B[CLI Tool]
A --> C[Web Interface]
A --> D[Native Apps]
E[Common Protocols] --> A
F[Shared APIs] --> A
The real value might come from standardizing the communication protocols and APIs across these tools, allowing them to evolve independently while maintaining interoperability. What do you think about starting with a shared library approach that the various tools could gradually adopt? |
|
While node.js sounds awesome, it adds a lot of moving parts. I’ve tried to keep this tool as barebones as possible, using built in functionality as much as possible.
That is also why my next step if built in tools aren’t enough, to make a compiled binary (one file) that works on all platforms (one per platform obviously) but doesn’t require further dependencies. I think node js can do that - but at the cost of the complexity etc.
To start with, I would go with a simple tool like my suggestion, without any gui or webpage, and have it simple to run and somewhat readable by any interested parties.
If it becomes immensely popular and has a wide reach, more dev time could be used.
Mike.
Sent from Outlook for iOS<https://aka.ms/o0ukef>
…________________________________
From: coderabbitai[bot] ***@***.***>
Sent: Wednesday, April 16, 2025 10:04:13 AM
To: wled/WLED ***@***.***>
Cc: Michael Bisbjerg ***@***.***>; Mention ***@***.***>
Subject: Re: [wled/WLED] Create wled-tools (PR #4625)
Tip
For best results, initiate chat on the files or code changes.
🧩 Analysis chain
@ewowi<https://github.com./ewowi> Thanks for sharing your feedback and your ESP32Instances project! After examining the wled-tools bash script, I can see how these different approaches complement each other in the WLED ecosystem.
The current bash script provides powerful command-line functionality for discovering, backing up, and updating WLED devices, which works well for Linux environments and likely Mac with some adjustments. Your node.js approach with ESP32Instances offers better cross-platform compatibility with a user-friendly web interface, though focused primarily on discovery.
Regarding creating a universal tool, I think there are several approaches worth considering:
1. Unified JavaScript/TypeScript Tool: A Node.js application could provide both CLI and web interfaces, working across all platforms while supporting the full range of functionality (discovery, backup, update).
2. Progressive Web App: Building on your HTML/JS approach, a PWA could offer platform-independent access with offline capabilities.
3. Separate Repo Organization: Your suggestion of a dedicated wled/WLED-tools repository makes a lot of sense - it would help organize these utilities while keeping the main WLED repo focused.
Each approach has its own audience - CLI tools for power users and automation, and GUI tools for broader accessibility. Rather than one universal solution replacing all others, perhaps a complementary ecosystem with shared core libraries would be most beneficial.
What are your thoughts on collaborating on core functionality while maintaining different interfaces for different user needs?
________________________________
🏁 Script executed:
#!/bin/bash
# Locate and examine the wled-tools.sh file
fd -t f "wled-tools"
cat tools/wled-tools
Length of output: 8662
________________________________
@ewowi<https://github.com./ewowi> Thanks for sharing your ESP32Instances project and your thoughts on the WLED tools ecosystem! After examining the wled-tools bash script, I can see the complementary approaches each tool is taking.
The current bash script provides powerful command-line capabilities for device discovery, backup, and firmware updates, while your Node.js approach offers better cross-platform compatibility with a user-friendly web interface. WLED-Native seems to focus on end-user experience, and the Bluetooth approach you're investigating could make device management even more accessible.
Regarding creating a universal tool, here are some thoughts:
1. Modular Architecture: A unified approach could use a core library (potentially in JavaScript/TypeScript) that handles the common functionality (discovery protocols, API interactions), with different interfaces (CLI, web, native) built on top.
2. Progressive Enhancement: Start with the most universal layer (web interface) and add platform-specific enhancements where available.
3. Separate Repository: Your suggestion of a dedicated wled/WLED-tools repository makes excellent sense - it would help organize these utilities while keeping the main WLED repo focused on core functionality.
Rather than one tool replacing all others, perhaps the most practical approach is a "family" of tools that share core components but are optimized for different use cases:
graph TD
A[Core Library] --> B[CLI Tool]
A --> C[Web Interface]
A --> D[Native Apps]
E[Common Protocols] --> A
F[Shared APIs] --> A
Loading
The real value might come from standardizing the communication protocols and APIs across these tools, allowing them to evolve independently while maintaining interoperability.
What do you think about starting with a shared library approach that the various tools could gradually adopt?
—
Reply to this email directly, view it on GitHub<#4625 (comment)>, or unsubscribe<https://github.com./notifications/unsubscribe-auth/AAH2YJZ3QFRO4PZE7UBDOPT2ZYFH3AVCNFSM6AAAAAB2BLJYCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMBYG42DAOBQGY>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
[https://avatars.githubusercontent.com/in/347564?s=20&v=4]coderabbitai[bot] left a comment (wled/WLED#4625)<#4625 (comment)>
Tip
For best results, initiate chat on the files or code changes.
🧩 Analysis chain
@ewowi<https://github.com./ewowi> Thanks for sharing your feedback and your ESP32Instances project! After examining the wled-tools bash script, I can see how these different approaches complement each other in the WLED ecosystem.
The current bash script provides powerful command-line functionality for discovering, backing up, and updating WLED devices, which works well for Linux environments and likely Mac with some adjustments. Your node.js approach with ESP32Instances offers better cross-platform compatibility with a user-friendly web interface, though focused primarily on discovery.
Regarding creating a universal tool, I think there are several approaches worth considering:
1. Unified JavaScript/TypeScript Tool: A Node.js application could provide both CLI and web interfaces, working across all platforms while supporting the full range of functionality (discovery, backup, update).
2. Progressive Web App: Building on your HTML/JS approach, a PWA could offer platform-independent access with offline capabilities.
3. Separate Repo Organization: Your suggestion of a dedicated wled/WLED-tools repository makes a lot of sense - it would help organize these utilities while keeping the main WLED repo focused.
Each approach has its own audience - CLI tools for power users and automation, and GUI tools for broader accessibility. Rather than one universal solution replacing all others, perhaps a complementary ecosystem with shared core libraries would be most beneficial.
What are your thoughts on collaborating on core functionality while maintaining different interfaces for different user needs?
________________________________
🏁 Script executed:
#!/bin/bash
# Locate and examine the wled-tools.sh file
fd -t f "wled-tools"
cat tools/wled-tools
Length of output: 8662
________________________________
@ewowi<https://github.com./ewowi> Thanks for sharing your ESP32Instances project and your thoughts on the WLED tools ecosystem! After examining the wled-tools bash script, I can see the complementary approaches each tool is taking.
The current bash script provides powerful command-line capabilities for device discovery, backup, and firmware updates, while your Node.js approach offers better cross-platform compatibility with a user-friendly web interface. WLED-Native seems to focus on end-user experience, and the Bluetooth approach you're investigating could make device management even more accessible.
Regarding creating a universal tool, here are some thoughts:
1. Modular Architecture: A unified approach could use a core library (potentially in JavaScript/TypeScript) that handles the common functionality (discovery protocols, API interactions), with different interfaces (CLI, web, native) built on top.
2. Progressive Enhancement: Start with the most universal layer (web interface) and add platform-specific enhancements where available.
3. Separate Repository: Your suggestion of a dedicated wled/WLED-tools repository makes excellent sense - it would help organize these utilities while keeping the main WLED repo focused on core functionality.
Rather than one tool replacing all others, perhaps the most practical approach is a "family" of tools that share core components but are optimized for different use cases:
graph TD
A[Core Library] --> B[CLI Tool]
A --> C[Web Interface]
A --> D[Native Apps]
E[Common Protocols] --> A
F[Shared APIs] --> A
Loading
The real value might come from standardizing the communication protocols and APIs across these tools, allowing them to evolve independently while maintaining interoperability.
What do you think about starting with a shared library approach that the various tools could gradually adopt?
—
Reply to this email directly, view it on GitHub<#4625 (comment)>, or unsubscribe<https://github.com./notifications/unsubscribe-auth/AAH2YJZ3QFRO4PZE7UBDOPT2ZYFH3AVCNFSM6AAAAAB2BLJYCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMBYG42DAOBQGY>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Per discussion #4621, add a discover-fueled tool to update/backup wled devices in the local network.
Todo:
Help text:
Example command:
Summary by CodeRabbit