When uploading large firmware binaries for OTA updates (files over 5MB), we’re hitting ‘413 Request Entity Too Large’ errors through the Cloud IoT Core API. Smaller firmware files (under 3MB) upload successfully, but our latest firmware version is 8.2MB and consistently fails.
We’re currently trying to push firmware directly through the device configuration update API, but I suspect we’re hitting API upload size limits. We need to understand proper signed URL usage for large file transfers and Cloud Storage integration patterns:
Error: 413 Request Entity Too Large
Firmware: device_fw_v2.5.bin (8.2MB)
API endpoint: /v1/projects/{project}/devices/{device}/config
This is blocking our rollout of critical security patches. What’s the recommended approach for distributing large firmware binaries to IoT devices through Google Cloud?
Implement resumable downloads using HTTP range requests. If download fails partway through, device can resume from where it left off rather than restarting. Also set reasonable timeouts and retry logic. For 8MB files over cellular networks, you might need 5-10 minute timeouts. Track download progress and report back to cloud so you can monitor rollout success rates.
Don’t forget firmware signature verification. When you send the download URL via config, also include a SHA-256 hash or digital signature of the firmware. Device should verify the downloaded binary matches the expected hash before flashing. This prevents tampering or corrupted downloads from bricking devices.
Yes, that’s exactly what we’re doing - trying to send the base64-encoded binary through the config API. That explains the size limit issue. So the pattern is: upload firmware to Cloud Storage, generate a download URL, send URL to device via config API, device downloads directly from Storage?
The device configuration API has a 64KB limit for config data - it’s not designed for firmware distribution. For firmware updates, you should store binaries in Cloud Storage and send only the download URL through the config API. The device then pulls the firmware directly from Cloud Storage. Are you currently trying to send the entire binary through the config API?
Good point on signature verification. So the config payload would contain: firmware_url, firmware_version, and firmware_sha256_hash. Device downloads, verifies hash, then flashes if valid. What about handling download failures or network interruptions during the transfer?