@alteriom/painlessmesh 1.7.7 → 1.7.8

package/CHANGELOG.md

@@ -19,7 +19,77 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 - TBD
 
-## [1.7.7] - 2025-10-23
+## [1.7.8] - 2025-11-04
+
+### Added
+
+- **BRIDGE_TO_INTERNET.md** - Comprehensive documentation for bridging mesh networks to the Internet via WiFi router
+  - Complete code examples with AP+STA mode configuration
+  - WiFi channel matching requirements and best practices
+  - Links to working bridge examples (basic, MQTT, web server, enhanced MQTT)
+  - Architecture diagrams and forwarding patterns
+  - Troubleshooting and additional resources
+
+- **Enhanced StatusPackage** - New organization and sensor configuration fields
+  - Organization fields: `organizationId`, `organizationName`, `organizationDomain`
+  - Sensor configuration: `sensorTypes` array, `sensorConfig` JSON, `sensorInventory` array
+  - Separate JSON serialization keys for sensors data vs configuration
+  - CamelCase field naming convention for consistency
+
+- **API Design Guidelines** - `docs/API_DESIGN_GUIDELINES.md`
+  - Field naming conventions (camelCase, units in field names)
+  - Boolean naming patterns (`is`, `has`, `should`, `can`)
+  - Time field naming with units (`_ms`, `_s`, `_us` suffixes)
+  - Serialization patterns and consistency rules
+  - Comprehensive validation tests
+
+- **Manual Publishing Workflow** - `.github/workflows/manual-publish.yml`
+  - On-demand NPM and GitHub Packages publishing
+  - Fixes cases where automated release doesn't trigger package publication
+  - Configurable options for selective publishing
+
+### Changed
+
+- **Time Field Naming Convention** - Consistent unit suffixes across all packages
+  - `collectionTimestamp` → `collectionTimestamp_ms`
+  - `avgResponseTime` → `avgResponseTime_us`
+  - `estimatedTimeToFailure` → `estimatedTimeToFailure_s`
+  - All time fields now include explicit units in field names
+  - Documentation: `docs/architecture/TIME_FIELD_NAMING.md`
+
+- **StatusPackage JSON Structure** - Improved field organization
+  - Sensor data uses `sensors` key (array of readings)
+  - Sensor configuration uses separate keys (`sensorTypes`, `sensorConfig`, `sensorInventory`)
+  - No key collisions between runtime data and configuration
+  - Unconditional serialization for predictable JSON structure
+
+- **MQTT Retry Logic** - Fixed serialization to include all retry fields
+  - Proper condition for including retry configuration
+  - Epsilon comparison for floating-point backoff multiplier
+
+### Fixed
+
+- **CI Pipeline** - Made validate-release depend on CI completion
+  - Prevents release validation from running before tests complete
+  - Ensures all tests pass before release can proceed
+
+- **ArduinoJson API** - Updated deprecated API usage
+  - Fixed deprecated JsonVariant::is<JsonObject>() calls
+  - Updated to ArduinoJson 7.x compatible patterns
+  - Code formatting improvements
+
+- **ESP8266 Compatibility** - Fixed `getDeviceId()` function
+  - Added proper ESP8266 implementation in mqttTopologyTest
+  - Platform-specific device ID retrieval
+
+- **Documentation** - Multiple improvements
+  - Fixed v1.7.7 release date in documentation
+  - Added comprehensive mqtt-schema v0.7.2+ message type codes table
+  - Corrected CommandPackage type number (400, not 201)
+  - Enhanced Alteriom Extensions section in README
+  - Added GitHub Packages authentication for npm install
+
+## [1.7.7] - 2025-11-05
 
 ### Added
 

package/README.md

@@ -245,9 +245,9 @@ void receivedCallback(uint32_t from, String& msg) {
 | Type | Class | Purpose | Fields |
 |------|-------|---------|--------|
 | 200 | `SensorPackage` | Environmental data | `temperature`, `humidity`, `pressure`, `sensorId`, `timestamp`, `batteryLevel` |
-| 201 | `CommandPackage` | Device control | `command`, `targetDevice`, `parameters`, `commandId` |
 | 202 | `StatusPackage` | Health monitoring | `deviceStatus`, `uptime`, `freeMemory`, `wifiStrength`, `firmwareVersion` |
 | 204 | `MetricsPackage` | Sensor metrics (v1.7.7+, aligns with schema v0.7.2+) | `cpuUsage`, `freeHeap`, `bytesReceived`, `currentThroughput`, `connectionQuality`, `wifiRSSI` |
+| 400 | `CommandPackage` | Device control (v1.7.7+, moved from 201) | `command`, `targetDevice`, `parameters`, `commandId` |
 | 600 | `MeshNodeListPackage` | Mesh node list (v1.7.7+, MESH_NODE_LIST) | `nodes[]` (nodeId, status, lastSeen, signalStrength), `nodeCount`, `meshId` |
 | 601 | `MeshTopologyPackage` | Mesh topology (v1.7.7+, MESH_TOPOLOGY) | `connections[]` (fromNode, toNode, linkQuality, latencyMs), `rootNode` |
 | 602 | `MeshAlertPackage` | Mesh alerts (v1.7.7+, MESH_ALERT) | `alerts[]` (alertType, severity, message, nodeId), `alertCount` |
@@ -282,16 +282,23 @@ void receivedCallback(uint32_t from, String& msg) {
 - **Event Coordination** - Synchronized displays, distributed processing
 - **Bridge Networks** - Connect mesh to WiFi/Internet/MQTT
 
-## Latest Release: v1.7.6 (October 19, 2025)
+## Development Version: v1.7.8
 
-**Critical emergency fix** for compilation failures in v1.7.4 and v1.7.5:
+**In Development** - Next release after v1.7.7
 
-- ✅ **Compilation Fixed** - Resolved "_task_request_t was not declared" error
-- ✅ **ESP32 & ESP8266** - All platforms now compile successfully  
-- ✅ **FreeRTOS Stability** - Maintained ~85% crash reduction on ESP32
-- 🚨 **v1.7.4/v1.7.5 Users** - Upgrade immediately (those versions don't compile)
+See [CHANGELOG](CHANGELOG.md) for upcoming changes.
 
-**[📋 Full Release Notes](docs/releases/RELEASE_SUMMARY_v1.7.6.md)** | **[🔖 CHANGELOG](CHANGELOG.md)**
+## Latest Release: v1.7.7 (November 5, 2025)
+
+**MQTT Schema v0.7.2 Compliance with Enhanced Monitoring**:
+
+- ✅ **MetricsPackage (Type 204)** - Comprehensive performance metrics for real-time monitoring
+- ✅ **HealthCheckPackage (Type 605)** - Proactive health monitoring with problem detection
+- ✅ **Mesh Topology Packages** - Complete network visualization (Types 600-603)
+- ✅ **Enhanced MQTT Bridge** - On-demand metrics, health checks, and aggregated statistics
+- ✅ **100% Backward Compatible** - All existing code continues to work
+
+**[📋 Full Release Notes](docs/releases/RELEASE_SUMMARY_v1.7.7.md)** | **[🔖 CHANGELOG](CHANGELOG.md)**
 
 ## Getting Help
 

package/docs/API_DESIGN_GUIDELINES.md

@@ -0,0 +1,414 @@
+# API Design Guidelines for Alteriom Packages
+
+This document provides guidelines for designing consistent and maintainable JSON configuration structures in Alteriom packages, particularly for StatusPackage and related message types.
+
+## Table of Contents
+
+- [Overview](#overview)
+- [Nesting vs Flat Structure Guidelines](#nesting-vs-flat-structure-guidelines)
+- [Current Structure Patterns](#current-structure-patterns)
+- [Decision Tree](#decision-tree)
+- [Examples](#examples)
+- [Best Practices](#best-practices)
+
+## Overview
+
+Alteriom packages use JSON serialization for configuration and status data. This document establishes clear patterns for when to use nested structures versus flat key-value pairs to ensure consistency and maintainability across the codebase.
+
+**Related Issues:**
+- [Issue #28](https://github.com/Alteriom/painlessMesh/issues/28) - Inconsistent Nested vs Flat Configuration Structure
+- [Issue #29](https://github.com/Alteriom/painlessMesh/issues/29) - Inconsistent Optional vs Required Field Serialization Pattern
+- [PR #36](https://github.com/Alteriom/painlessMesh/pull/36) - Documented nesting patterns (this file)
+- [PR #37](https://github.com/Alteriom/painlessMesh/pull/37) - Removed conditional serialization for predictable JSON structure
+
+### Key Principles
+
+1. **Consistency over perfection** - Follow existing patterns in similar sections
+2. **Simplicity by default** - Use flat structures unless nesting provides clear benefits
+3. **Future-proof** - Consider extensibility when designing structures
+4. **Clarity** - Structure should reflect logical grouping
+5. **Predictable structure** - All sections always serialize with default values (addressed in PR #37)
+
+## Nesting vs Flat Structure Guidelines
+
+### Use FLAT Structure When:
+
+- **< 4 total fields** in a configuration section
+- **No clear logical subsystems** within the section
+- **Simple value types** without complex relationships
+- **Low likelihood of expansion** in the future
+
+**Benefits:**
+- Simpler code (fewer nested object creations)
+- Easier to parse and validate
+- More concise JSON output
+- Faster serialization/deserialization
+
+### Use NESTED Structure When:
+
+- **3+ fields belong to same logical subsystem**
+- **Clear semantic grouping** exists
+- **Future extensibility anticipated** for subsystem
+- **Subsystem has distinct meaning** separate from parent
+
+**Benefits:**
+- Better logical organization
+- Easier to add related fields without cluttering parent
+- Clear separation of concerns
+- More extensible architecture
+
+## Current Structure Patterns
+
+**Important Note (as of PR #37):** All configuration sections now **always serialize** regardless of whether values are at their defaults. This provides predictable JSON structure and eliminates the need for consumers to check key existence. Default values (0, false, "") clearly indicate "not configured" state.
+
+### Flat Sections (No Nesting)
+
+These sections use simple key-value pairs at a single level:
+
+#### Display Configuration
+```json
+"display_config": {
+  "enabled": true,
+  "brightness": 128,
+  "timeout_ms": 30000,
+  "timeout_s": 30
+}
+```
+
+**Rationale:** Only 3-4 fields, all directly related to display, no subsystems.
+
+#### Power Configuration
+```json
+"power_config": {
+  "deep_sleep_enabled": false,
+  "deep_sleep_interval_ms": 300000,
+  "deep_sleep_interval_s": 300,
+  "battery_percent": 85
+}
+```
+
+**Rationale:** Small number of fields (4), even though battery and sleep are different concerns, nesting would add unnecessary complexity.
+
+#### MQTT Retry Configuration
+```json
+"mqtt_retry": {
+  "max_attempts": 5,
+  "circuit_breaker_ms": 60000,
+  "circuit_breaker_s": 60,
+  "hourly_retry_enabled": true,
+  "initial_retry_ms": 1000,
+  "initial_retry_s": 1,
+  "max_retry_ms": 30000,
+  "max_retry_s": 30,
+  "backoff_multiplier": 2.0
+}
+```
+
+**Rationale:** While this has 9 fields with distinct concerns (retry policy vs backoff strategy), it remains flat for simplicity. The retry configuration is cohesive enough that nesting would fragment it without clear benefit.
+
+### Nested Sections (With Subsystems)
+
+These sections use nested objects for logical grouping:
+
+#### Sensor Configuration with Calibration
+```json
+"sensors": {
+  "read_interval_ms": 30000,
+  "read_interval_s": 30,
+  "transmission_interval_ms": 60000,
+  "transmission_interval_s": 60,
+  "calibration": {
+    "temperature_offset": 0.5,
+    "humidity_offset": -2.0,
+    "pressure_offset": 0.0
+  }
+}
+```
+
+**Rationale:** Calibration is a distinct subsystem with its own semantic meaning. It's optional, extensible, and conceptually separate from sensor timing configuration.
+
+**Benefits of nesting here:**
+- Calibration can be added/removed as a unit
+- Easy to add more calibration fields without cluttering main sensors object
+- Clear semantic boundary - calibration is a specific tuning operation
+
+#### Organization Metadata
+```json
+"organization": {
+  "organizationId": "org-123",
+  "customerId": "cust-456",
+  "deviceGroup": "sensors",
+  "device_name": "sensor-01",
+  "device_location": "warehouse-a",
+  "device_secret_set": true
+}
+```
+
+**Rationale:** Organization metadata is an optional, self-contained subsystem that may not be present on all devices.
+
+## Decision Tree
+
+Use this decision tree when designing new configuration sections:
+
+```
+START: New configuration section needed
+│
+├─ Does section have < 4 fields?
+│  ├─ YES → Use FLAT structure
+│  └─ NO → Continue
+│
+├─ Do 3+ fields belong to same logical subsystem?
+│  ├─ NO → Use FLAT structure
+│  └─ YES → Continue
+│
+├─ Is subsystem likely to grow in future?
+│  ├─ NO → Consider FLAT (unless strong semantic grouping)
+│  └─ YES → Continue
+│
+├─ Would nesting improve clarity significantly?
+│  ├─ NO → Use FLAT structure
+│  └─ YES → Use NESTED structure
+│
+END
+```
+
+## Examples
+
+### Example 1: Adding OTA Configuration (Flat Approach)
+
+**Scenario:** Adding Over-The-Air update configuration with 3 fields.
+
+```cpp
+// C++ Fields
+bool otaEnabled = false;
+TSTRING otaServer = "";
+uint16_t otaPort = 0;
+
+// JSON Serialization (FLAT)
+JsonObject ota = jsonObj["ota"].to<JsonObject>();
+ota["enabled"] = otaEnabled;
+ota["server"] = otaServer;
+ota["port"] = otaPort;
+```
+
+**Result:**
+```json
+"ota": {
+  "enabled": true,
+  "server": "ota.example.com",
+  "port": 8080
+}
+```
+
+**Decision:** Keep FLAT - only 3 fields, no subsystems.
+
+### Example 2: Adding Sensor Thresholds (Nested Approach)
+
+**Scenario:** Adding temperature, humidity, and pressure thresholds to sensor configuration.
+
+```cpp
+// C++ Fields (added to existing sensor config)
+double tempThresholdMin = -40.0;
+double tempThresholdMax = 85.0;
+double humidityThresholdMin = 0.0;
+double humidityThresholdMax = 100.0;
+
+// JSON Serialization (NESTED under sensors)
+JsonObject sensors = jsonObj["sensors"].to<JsonObject>();
+// ... existing sensor fields ...
+
+JsonObject thresholds = sensors["thresholds"].to<JsonObject>();
+thresholds["temperature_min"] = tempThresholdMin;
+thresholds["temperature_max"] = tempThresholdMax;
+thresholds["humidity_min"] = humidityThresholdMin;
+thresholds["humidity_max"] = humidityThresholdMax;
+```
+
+**Result:**
+```json
+"sensors": {
+  "read_interval_ms": 30000,
+  "calibration": { ... },
+  "thresholds": {
+    "temperature_min": -40.0,
+    "temperature_max": 85.0,
+    "humidity_min": 0.0,
+    "humidity_max": 100.0
+  }
+}
+```
+
+**Decision:** Use NESTED - 4+ fields, clear subsystem (alerting/validation logic), logical grouping.
+
+### Example 3: Adding Encoding Configuration (Flat Approach)
+
+**Scenario:** Adding message encoding/compression settings.
+
+```cpp
+// C++ Fields
+bool compressionEnabled = false;
+TSTRING encodingType = "json";
+uint8_t compressionLevel = 6;
+
+// JSON Serialization (FLAT)
+JsonObject encoding = jsonObj["encoding"].to<JsonObject>();
+encoding["compression_enabled"] = compressionEnabled;
+encoding["encoding_type"] = encodingType;
+encoding["compression_level"] = compressionLevel;
+```
+
+**Result:**
+```json
+"encoding": {
+  "compression_enabled": false,
+  "encoding_type": "json",
+  "compression_level": 6
+}
+```
+
+**Decision:** Keep FLAT - only 3 fields, cohesive purpose.
+
+## Best Practices
+
+### 1. Be Conservative with Nesting
+
+**Rationale:** Flat structures are simpler to implement and consume.
+
+**Rule:** When in doubt, start flat. Nesting can be added later if needed, but removing nesting is a breaking change.
+
+### 2. Consider Backward Compatibility
+
+When adding fields to existing sections:
+
+```cpp
+// Deserialization with backward compatibility
+displayTimeout = displayConfig["timeout_ms"] | displayConfig["timeout"] | 0;
+```
+
+This allows reading old format (`timeout`) while preferring new format (`timeout_ms`).
+
+### 3. Group Optional Subsystems
+
+**Good:**
+```json
+"sensors": {
+  "read_interval_ms": 30000,
+  "calibration": { ... }  // Optional, can be omitted entirely
+}
+```
+
+**Avoid:**
+```json
+"sensors": {
+  "read_interval_ms": 30000,
+  "temperature_offset": 0.0,  // Mixed levels - unclear if calibration is a concept
+  "humidity_offset": 0.0,
+  "pressure_offset": 0.0
+}
+```
+
+### 4. Maintain Consistent Field Naming
+
+Follow existing conventions:
+- Time fields: Follow [Time Field Naming Convention](../examples/alteriom/alteriom_sensor_package.hpp#L10-L55)
+- Boolean fields: Follow [Boolean Naming Convention](BOOLEAN_NAMING_CONVENTION.md)
+- Use snake_case for JSON keys
+- Use camelCase for C++ field names
+
+### 5. Document Structure Decisions
+
+Add comments explaining nesting choices:
+
+```cpp
+// Display configuration (flat - only 3 fields, no subsystems)
+JsonObject displayConfig = jsonObj["display_config"].to<JsonObject>();
+
+// Sensor configuration with nested calibration (calibration is distinct subsystem)
+JsonObject sensors = jsonObj["sensors"].to<JsonObject>();
+JsonObject calibration = sensors["calibration"].to<JsonObject>();
+```
+
+### 6. Test Structure Consistency
+
+Create tests to validate structure patterns:
+
+```cpp
+TEST(StatusPackage, StructureConsistency) {
+    alteriom::StatusPackage pkg;
+    pkg.tempOffset = 0.5;
+    
+    JsonDocument doc;
+    JsonObject obj = doc.to<JsonObject>();
+    pkg.addTo(std::move(obj));
+    
+    // Verify nested structures
+    REQUIRE(obj["sensors"]["calibration"].is<JsonObject>());
+    
+    // Verify flat structures remain flat
+    REQUIRE(obj["display_config"]["enabled"].is<bool>());
+    REQUIRE_FALSE(obj["display_config"].containsKey("nested_section"));
+}
+```
+
+## Migration Path
+
+If restructuring becomes necessary:
+
+1. **Add new structure** while maintaining old structure
+2. **Support both formats** in deserialization
+3. **Deprecate old format** (document in release notes)
+4. **Remove old format** in next major version
+
+```cpp
+// Example: Supporting both flat and nested
+if (jsonObj["network"]["wifi"].is<JsonObject>()) {
+    // New nested format
+    JsonObject wifi = jsonObj["network"]["wifi"];
+    wifiSSID = wifi["ssid"].as<TSTRING>();
+} else {
+    // Old flat format (deprecated)
+    wifiSSID = jsonObj["network"]["wifi_ssid"].as<TSTRING>();
+}
+```
+
+## Summary
+
+| Criteria | Flat Structure | Nested Structure |
+|----------|---------------|------------------|
+| **Field Count** | < 4 fields | 3+ fields in subsystem |
+| **Logical Grouping** | No clear subsystems | Clear semantic grouping |
+| **Extensibility** | Low likelihood of growth | Anticipated expansion |
+| **Complexity** | Simple values | Complex relationships |
+| **Serialization** | Always present (PR #37) | Always present (PR #37) |
+| **Examples** | display_config, power_config, ota, encoding, mqtt_retry | sensors.calibration, organization |
+
+**Golden Rule:** When uncertain, prefer flat structures. Nesting should provide clear organizational or extensibility benefits to justify the added complexity.
+
+### Resolution of Issue #28
+
+Issue #28 identified inconsistent nesting patterns and proposed three options:
+
+1. **Option 1: Keep Current Structure (Document Pattern)** ✅ **ADOPTED**
+2. Option 2: Nest Network Configuration (Breaking Change)
+3. Option 3: Nest MQTT Retry Backoff Settings (Minimal Change)
+
+**Decision Rationale:**
+- Current flat structure for most sections (display_config, power_config, mqtt_retry) is functional and simple
+- Only sensors.calibration uses nesting, which is justified by its semantic separation
+- Avoiding breaking changes preserves compatibility with existing consumers
+- Clear documentation (this file) addresses the inconsistency concern
+- PR #37's unconditional serialization provides the predictable structure that was the real underlying concern
+
+**Result:** The pattern is now documented and validated. Future additions should follow the decision tree in this document.
+
+## References
+
+- [StatusPackage Implementation](../examples/alteriom/alteriom_sensor_package.hpp)
+- [Boolean Naming Convention](BOOLEAN_NAMING_CONVENTION.md)
+- [Time Field Naming Convention](../examples/alteriom/alteriom_sensor_package.hpp#L10-L55)
+- [Test Cases](../test/catch/catch_alteriom_packages.cpp)
+
+## Revision History
+
+- **2025-11-04 (PR #37)**: Updated to reflect unconditional serialization pattern - all sections always serialize with default values for predictable structure
+- **2025-11-04 (PR #36)**: Initial version documenting StatusPackage nesting patterns in response to Issue #28

package/docs/BOOLEAN_NAMING_CONVENTION.md

@@ -0,0 +1,235 @@
+# Boolean Field Naming Convention
+
+**Related Issue**: #27
+
+## Overview
+
+This document establishes the standard naming conventions for boolean fields in Alteriom packages, particularly in `StatusPackage`. Consistent naming patterns make the code self-documenting and help developers understand field semantics at a glance.
+
+## Three Naming Patterns
+
+### Pattern 1: `*Set` Suffix
+
+**Purpose**: Indicates that required configuration data has been provided (typically for sensitive data like passwords or secrets).
+
+**When to use**:
+- Field represents whether configuration data exists
+- Typically used for passwords, secrets, API keys, server URLs
+- Does NOT indicate if the feature is active or working
+
+**Examples**:
+```cpp
+bool deviceSecretSet = false;  // Has device secret been configured?
+bool wifiPasswordSet = false;  // Has WiFi password been provided?
+bool meshPasswordSet = false;  // Has mesh password been provided?
+bool otaServerSet = false;     // Has OTA server URL been configured?
+bool mqttBrokerSet = false;    // Has MQTT broker been configured?
+```
+
+**Semantic meaning**:
+- `true` = Configuration data has been provided
+- `false` = Configuration data is missing or not yet provided
+- Does NOT indicate the feature is enabled or currently working
+
+### Pattern 2: `*Enabled` Suffix
+
+**Purpose**: Indicates that a feature is currently active or turned on.
+
+**When to use**:
+- Field represents a feature toggle (on/off)
+- User or system can enable/disable the feature
+- Feature state is controllable and intentional
+
+**Examples**:
+```cpp
+bool displayEnabled = false;           // Is display feature enabled?
+bool deepSleepEnabled = false;         // Is deep sleep mode enabled?
+bool mqttHourlyRetryEnabled = false;   // Is hourly retry feature enabled?
+bool otaEnabled = false;               // Are OTA updates enabled?
+bool encryptionEnabled = false;        // Is data encryption enabled?
+bool encodingEnabled = false;          // Is data encoding enabled?
+bool logTimestampEnabled = false;      // Are log timestamps enabled?
+```
+
+**Semantic meaning**:
+- `true` = Feature is currently active/turned on
+- `false` = Feature is currently inactive/turned off
+- Independent of whether required configuration exists
+
+### Pattern 3: Runtime State (`is*` Prefix or `*Connected`)
+
+**Purpose**: Indicates current runtime status or operational state (not configuration).
+
+**When to use**:
+- Field represents current operational status
+- Status changes at runtime based on system behavior
+- Not directly controlled by configuration
+
+**Examples**:
+```cpp
+bool isConfigured = false;    // Has device completed configuration?
+bool mqttConnected = false;   // Currently connected to MQTT broker?
+bool meshIsRoot = false;      // Is this node currently the mesh root?
+bool isOnline = false;        // Is device currently online?
+bool wifiConnected = false;   // Currently connected to WiFi?
+```
+
+**Semantic meaning**:
+- `true` = Currently in this state
+- `false` = Not currently in this state
+- Reflects actual runtime conditions, not configuration
+
+## Combining Patterns
+
+A feature may legitimately have multiple boolean fields using different patterns:
+
+### Example: OTA (Over-The-Air) Updates
+
+```cpp
+bool otaServerSet = false;     // Has OTA server URL been configured? (*Set)
+bool otaEnabled = false;       // Are OTA updates enabled? (*Enabled)
+bool otaInProgress = false;    // Is an OTA update currently running? (is* / runtime state)
+```
+
+**Valid states**:
+- `otaServerSet=true, otaEnabled=false` → Server configured but feature disabled
+- `otaServerSet=false, otaEnabled=true` → Feature enabled but no server (invalid/warning state)
+- `otaServerSet=true, otaEnabled=true` → Fully configured and active
+- `otaServerSet=true, otaEnabled=true, otaInProgress=true` → Update in progress
+
+### Example: MQTT Connection
+
+```cpp
+bool mqttBrokerSet = false;    // Has MQTT broker been configured? (*Set)
+bool mqttEnabled = false;      // Is MQTT feature enabled? (*Enabled)
+bool mqttConnected = false;    // Currently connected to broker? (runtime state)
+```
+
+## Current StatusPackage Implementation
+
+### Existing `*Set` Fields (Build 8057)
+```cpp
+bool deviceSecretSet = false;  // Whether device secret is configured
+```
+
+**Potential additions** (if needed):
+```cpp
+bool wifiPasswordSet = false;  // Whether WiFi password is configured
+bool meshPasswordSet = false;  // Whether mesh password is configured
+bool mqttBrokerSet = false;    // Whether MQTT broker is configured
+bool otaServerSet = false;     // Whether OTA server URL is configured
+```
+
+### Existing `*Enabled` Fields
+```cpp
+bool displayEnabled = false;           // Display feature enabled
+bool deepSleepEnabled = false;         // Deep sleep feature enabled
+bool mqttHourlyRetryEnabled = false;   // Hourly retry feature enabled
+```
+
+**Potential additions** (if needed):
+```cpp
+bool meshEnabled = false;       // Is WiFi mesh feature enabled?
+bool otaEnabled = false;        // Are OTA updates enabled?
+bool encryptionEnabled = false; // Is encryption enabled?
+bool encodingEnabled = false;   // Is data encoding enabled?
+```
+
+### Potential Runtime State Fields
+Currently, StatusPackage does not have explicit runtime state fields. If needed in the future:
+
+```cpp
+bool isConfigured = false;      // Device has complete valid configuration
+bool mqttConnected = false;     // Currently connected to MQTT broker
+bool meshIsRoot = false;        // Currently acting as mesh root
+bool wifiConnected = false;     // Currently connected to WiFi
+```
+
+## Best Practices
+
+### DO ✅
+
+1. **Use `*Set` for configuration presence**
+   ```cpp
+   bool deviceSecretSet = false;  // ✅ Indicates if secret is configured
+   ```
+
+2. **Use `*Enabled` for feature toggles**
+   ```cpp
+   bool displayEnabled = false;   // ✅ Indicates if feature is on/off
+   ```
+
+3. **Use `is*` or `*Connected` for runtime state**
+   ```cpp
+   bool isConfigured = false;     // ✅ Indicates current state
+   bool mqttConnected = false;    // ✅ Indicates connection status
+   ```
+
+4. **Document field purpose clearly**
+   ```cpp
+   bool otaServerSet = false;     // Has OTA server URL been configured? (Build XXXX)
+   ```
+
+### DON'T ❌
+
+1. **Don't mix patterns without clear semantics**
+   ```cpp
+   bool wifiSet = false;          // ❌ Ambiguous - set to what? On/off or configured?
+   ```
+
+2. **Don't use generic boolean names**
+   ```cpp
+   bool wifi = false;             // ❌ Unclear meaning
+   bool display = false;          // ❌ What about display?
+   ```
+
+3. **Don't use `*Set` for feature toggles**
+   ```cpp
+   bool displaySet = false;       // ❌ Confusing - use displayEnabled instead
+   ```
+
+4. **Don't use `*Enabled` for configuration presence**
+   ```cpp
+   bool deviceSecretEnabled = false;  // ❌ Confusing - use deviceSecretSet instead
+   ```
+
+## Validation
+
+When adding new boolean fields, ask these questions:
+
+1. **Does this field indicate configuration presence?**
+   - YES → Use `*Set` suffix
+   - Example: `mqttBrokerSet`, `deviceSecretSet`
+
+2. **Does this field toggle a feature on/off?**
+   - YES → Use `*Enabled` suffix
+   - Example: `displayEnabled`, `otaEnabled`
+
+3. **Does this field reflect current runtime state?**
+   - YES → Use `is*` prefix or `*Connected` suffix
+   - Example: `isConfigured`, `mqttConnected`
+
+4. **Does this field fit multiple categories?**
+   - Consider creating separate fields for each semantic meaning
+   - Example: `otaServerSet` AND `otaEnabled` AND `otaInProgress`
+
+## Benefits
+
+1. **Self-Documenting Code**: Field names clearly indicate semantic meaning
+2. **Reduced Confusion**: Developers immediately understand what each boolean represents
+3. **Better API Design**: Consistent patterns across entire codebase
+4. **Easier Onboarding**: New developers can infer meaning from field names
+5. **Fewer Bugs**: Clear semantics reduce misunderstandings and implementation errors
+
+## References
+
+- StatusPackage implementation: `examples/alteriom/alteriom_sensor_package.hpp`
+- Test validation: `test/catch/catch_alteriom_packages.cpp`
+- Time field conventions: See header documentation in `alteriom_sensor_package.hpp`
+
+---
+
+**Document Version**: 1.0  
+**Last Updated**: 2025-11-04  
+**Status**: Active  
+**Applies To**: StatusPackage, EnhancedStatusPackage, and all future Alteriom packages

package/docs/alteriom/overview.md

@@ -498,11 +498,34 @@ public:
 3. **Validate under memory pressure**
 4. **Test with maximum expected node count**
 
+## Code Conventions
+
+### Boolean Field Naming
+
+Alteriom packages follow a consistent naming convention for boolean fields to improve code clarity:
+
+- **`*Set` suffix**: Configuration data has been provided (e.g., `deviceSecretSet`)
+- **`*Enabled` suffix**: Feature is currently active (e.g., `displayEnabled`)
+- **`is*` prefix or `*Connected`**: Current runtime state (e.g., `mqttConnected`)
+
+See [Boolean Naming Convention](../BOOLEAN_NAMING_CONVENTION.md) for complete guidelines.
+
+### Time Field Naming
+
+Time-based configuration fields follow a dual-unit convention:
+
+- **Internal storage**: Always milliseconds (e.g., `sensorReadInterval`)
+- **JSON serialization**: Both milliseconds (`_ms`) and seconds (`_s`) variants
+- **JSON deserialization**: Read from milliseconds (`_ms`) variant
+
+See package header documentation for complete details.
+
 ## Next Steps
 
 - Learn about [Sensor Packages](sensor-packages.md) in detail
 - Explore [Command System](command-system.md) implementation
 - Study [Status Monitoring](status-monitoring.md) patterns
+- Review [Boolean Naming Convention](../BOOLEAN_NAMING_CONVENTION.md) guidelines
 - See [Tutorial Examples](../tutorials/sensor-networks.md) for hands-on practice
 
 The Alteriom extensions provide a solid foundation for building robust IoT applications with painlessMesh. They demonstrate production-ready patterns while remaining flexible enough to adapt to your specific needs.

package/docs/releases/RELEASE_SUMMARY_v1.7.7.md

@@ -1,6 +1,6 @@
 # painlessMesh v1.7.7 Release Summary
 
-**Release Date:** October 23, 2025  
+**Release Date:** November 5, 2025  
 **Version:** 1.7.7  
 **Type:** Feature Release  
 **Compatibility:** 100% backward compatible with v1.7.6

package/docs/v1.7.7_MQTT_IMPROVEMENTS.md

@@ -350,9 +350,27 @@ Packages now include the `message_type` field for 90% faster message classificat
 }
 ```
 
-**Message Type Codes:**
-- **204:** MetricsPackage - SENSOR_METRICS (aligns with schema v0.7.2+)
-- **605:** HealthCheckPackage - MESH_METRICS (mesh performance health)
+**Message Type Codes (mqtt-schema v0.7.2+):**
+
+For performance optimization and standardized routing, all Alteriom packages include the `message_type` field:
+
+| Code | Constant | Message Type | Category | Description | PainlessMesh Package |
+|------|----------|--------------|----------|-------------|---------------------|
+| 200 | SENSOR_DATA | sensor_data | telemetry | Sensor telemetry readings | SensorPackage |
+| 202 | SENSOR_STATUS | sensor_status | telemetry | Sensor status change | StatusPackage |
+| 204 | SENSOR_METRICS | sensor_metrics | telemetry | Sensor health and performance metrics | MetricsPackage |
+| 400 | COMMAND | command | control | Device control command | CommandPackage |
+| 600 | MESH_NODE_LIST | mesh_node_list | mesh | Mesh node inventory | MeshNodeListPackage |
+| 601 | MESH_TOPOLOGY | mesh_topology | mesh | Mesh network topology | MeshTopologyPackage |
+| 602 | MESH_ALERT | mesh_alert | mesh | Mesh network alert | MeshAlertPackage |
+| 603 | MESH_BRIDGE | mesh_bridge | mesh | Mesh protocol bridge | MeshBridgePackage |
+| 604 | MESH_STATUS | mesh_status | mesh | Mesh network health status | EnhancedStatusPackage |
+| 605 | MESH_METRICS | mesh_metrics | mesh | Mesh network performance metrics | HealthCheckPackage |
+
+**Key Points:**
+- The `message_type` field enables 90% faster message classification compared to parsing JSON
+- All Alteriom packages align with @alteriom/mqtt-schema v0.7.2+ standards
+- Message type codes are consistent across MQTT bridge, gateway, and mesh nodes
 
 ## Implementation Guide
 

package/examples/alteriom/README.md

@@ -271,4 +271,16 @@ This validates:
 - Package type consistency
 - Field preservation
 - Edge case handling
-- Integration with painlessMesh plugin system
+- Integration with painlessMesh plugin system
+- JSON structure consistency (nested vs flat)
+
+## Documentation
+
+For developers adding new configuration fields to Alteriom packages:
+
+- **[API Design Guidelines](../../docs/API_DESIGN_GUIDELINES.md)** - Comprehensive guide on when to use nested vs flat JSON structures
+- **[Time Field Naming Convention](alteriom_sensor_package.hpp#L10-L55)** - How to handle time-based fields (ms/s variants)
+- **[Boolean Naming Convention](../../docs/BOOLEAN_NAMING_CONVENTION.md)** - Consistent patterns for boolean fields (*Set, *Enabled, is*)
+- **[JSON Structure Guidelines](alteriom_sensor_package.hpp#L57-L121)** - Quick reference for nesting patterns
+
+These guidelines ensure consistency and maintainability across all Alteriom packages.

package/examples/alteriom/alteriom_sensor_package.hpp

@@ -3,6 +3,133 @@
 
 #include "painlessmesh/plugin.hpp"
 
+/**
+ * @file alteriom_sensor_package.hpp
+ * @brief Alteriom custom package definitions for painlessMesh
+ *
+ * TIME FIELD NAMING CONVENTION
+ * ============================
+ *
+ * For consistency and developer convenience, all time-based configuration
+ * fields in Alteriom packages follow a standardized naming convention:
+ *
+ * INTERNAL STORAGE:
+ * - Always use milliseconds (uint32_t)
+ * - Use descriptive field names WITHOUT unit suffixes
+ *   Examples: sensorReadInterval, transmissionInterval
+ *
+ * JSON SERIALIZATION:
+ * - ALWAYS provide BOTH millisecond and second variants:
+ *   - {fieldname}_ms : The value in milliseconds (uint32_t)
+ *   - {fieldname}_s  : The value in seconds (uint32_t, calculated as ms/1000)
+ *
+ * JSON DESERIALIZATION:
+ * - Read from the _ms variant (milliseconds are the source of truth)
+ * - The _s variant is provided for consumer convenience but not used for input
+ *
+ * EXAMPLE:
+ * ```cpp
+ * // C++ field declaration
+ * uint32_t sensorReadInterval = 0;  // Internal storage in milliseconds
+ *
+ * // JSON serialization (in addTo method)
+ * sensors["read_interval_ms"] = sensorReadInterval;           // 30000
+ * sensors["read_interval_s"] = sensorReadInterval / 1000;     // 30
+ *
+ * // JSON deserialization (in constructor)
+ * sensorReadInterval = sensors["read_interval_ms"] | 0;
+ * ```
+ *
+ * BENEFITS:
+ * - Consumer Convenience: No mental overhead for unit conversion
+ * - Flexibility: Consumers choose the unit appropriate for their context
+ * - Self-Documenting: Field names clearly indicate available units
+ * - Precision: Millisecond precision preserved, seconds for readability
+ * - Consistency: Predictable pattern across all time-based fields
+ *
+ * WHEN TO APPLY:
+ * - Use this convention for ALL time-based configuration/interval fields
+ * - Applies to fields typically >= 1000ms (1 second)
+ * - Examples: intervals, timeouts, durations, delays
+ * - Does NOT apply to timestamps (which should remain in seconds as per Unix
+ * convention)
+ *
+ *
+ * JSON STRUCTURE NESTING GUIDELINES
+ * ==================================
+ *
+ * Alteriom packages follow consistent patterns for organizing configuration
+ * data in JSON structures. This ensures maintainability and predictability
+ * across the API.
+ *
+ * IMPORTANT: As of PR #37, ALL configuration sections always serialize with
+ * default values, providing predictable JSON structure. Consumers no longer
+ * need to check for key existence. Default values (0, false, "") indicate "not
+ * configured" state.
+ *
+ * See docs/API_DESIGN_GUIDELINES.md for comprehensive documentation.
+ *
+ * QUICK REFERENCE:
+ *
+ * Use FLAT structure (simple key-value pairs) when:
+ * - Section has < 4 total fields
+ * - No clear logical subsystems
+ * - Simple value types
+ *
+ * Use NESTED structure (grouped subsections) when:
+ * - 3+ fields belong to same logical subsystem
+ * - Clear semantic grouping exists
+ * - Future extensibility anticipated
+ * - Subsystem has distinct meaning
+ *
+ * CURRENT STRUCTURE PATTERNS:
+ *
+ * Flat Sections:
+ * - display_config: enabled, brightness, timeout (3 fields, no subsystems)
+ * - power_config: deep_sleep_enabled, deep_sleep_interval, battery_percent (3
+ * fields)
+ * - mqtt_retry: retry settings and backoff parameters (9 fields, cohesive
+ * purpose)
+ * - ota: enabled, server, port (3 fields)
+ * - encoding: compression and format settings (3 fields)
+ *
+ * Nested Sections:
+ * - sensors.calibration: temperature_offset, humidity_offset, pressure_offset
+ *   (Rationale: Calibration is distinct subsystem, optional, semantically
+ * separate)
+ * - organization: organizationId, customerId, deviceGroup, device_name, etc.
+ *   (Rationale: Optional metadata subsystem, may not be present on all devices)
+ *
+ * EXAMPLES:
+ *
+ * Flat structure:
+ * ```json
+ * "display_config": {
+ *   "enabled": true,
+ *   "brightness": 128,
+ *   "timeout_ms": 30000,
+ *   "timeout_s": 30
+ * }
+ * ```
+ *
+ * Nested structure:
+ * ```json
+ * "sensors": {
+ *   "read_interval_ms": 30000,
+ *   "read_interval_s": 30,
+ *   "calibration": {
+ *     "temperature_offset": 0.5,
+ *     "humidity_offset": -2.0,
+ *     "pressure_offset": 0.0
+ *   }
+ * }
+ * ```
+ *
+ * DECISION RULE:
+ * When in doubt, prefer flat structures. Nesting should provide clear
+ * organizational or extensibility benefits to justify the added complexity.
+ */
+
 namespace alteriom {
 
 /**
@@ -94,6 +221,33 @@ class CommandPackage : public painlessmesh::plugin::SinglePackage {
 
 /**
  * @brief Status report package for device health monitoring
+ *
+ * BOOLEAN FIELD NAMING CONVENTION
+ * ================================
+ *
+ * This package follows a standardized naming convention for boolean fields
+ * to improve code clarity and reduce ambiguity. See
+ * docs/BOOLEAN_NAMING_CONVENTION.md for complete documentation.
+ *
+ * Three patterns are used:
+ *
+ * 1. *Set suffix: Configuration data has been provided
+ *    Example: deviceSecretSet = true means secret is configured
+ *    Does NOT indicate if feature is enabled or working
+ *
+ * 2. *Enabled suffix: Feature is currently active/turned on
+ *    Example: displayEnabled = true means display feature is active
+ *    Independent of whether required configuration exists
+ *
+ * 3. is* prefix or *Connected: Current runtime state
+ *    Example: mqttConnected = true means currently connected
+ *    Reflects actual runtime conditions, not configuration
+ *
+ * A feature may have both *Set and *Enabled fields:
+ * - otaServerSet=true, otaEnabled=false: Server configured but feature disabled
+ * - otaServerSet=false, otaEnabled=true: Feature enabled but no server
+ * (invalid)
+ * - otaServerSet=true, otaEnabled=true: Fully configured and active
  */
 class StatusPackage : public painlessmesh::plugin::BroadcastPackage {
  public:
@@ -107,6 +261,50 @@ class StatusPackage : public painlessmesh::plugin::BroadcastPackage {
   uint32_t responseToCommand = 0;  // CommandId this is responding to
   TSTRING responseMessage = "";    // Success/error message
 
+  // Organization metadata (Build 8052 - Phase 2.7)
+  TSTRING organizationId = "";  // Organization identifier
+  TSTRING customerId = "";      // Customer identifier
+  TSTRING deviceGroup = "";     // Device group/category
+  TSTRING deviceName = "";      // Device name
+  TSTRING deviceLocation = "";  // Device location
+  bool deviceSecretSet =
+      false;  // *Set: Has device secret been configured? (not enabled/disabled)
+
+  // Sensor configuration (Build 8057 - Gateway format compatibility)
+  // Note: Time fields follow Alteriom time field naming convention (see file
+  // header) Stored in milliseconds, serialized as both _ms and _s variants
+  uint32_t sensorReadInterval = 0;    // Sensor read interval in milliseconds
+  uint32_t transmissionInterval = 0;  // Transmission interval in milliseconds
+  double tempOffset = 0.0;            // Temperature calibration offset
+  double humidityOffset = 0.0;        // Humidity calibration offset
+  double pressureOffset = 0.0;        // Pressure calibration offset
+
+  // Sensor inventory (Build 8057 - Separate from config to avoid collision)
+  uint8_t sensorCount = 0;     // Number of sensors attached
+  uint8_t sensorTypeMask = 0;  // Bitmask of sensor types present
+
+  // Display configuration
+  bool displayEnabled =
+      false;  // *Enabled: Is display feature currently active?
+  uint8_t displayBrightness = 0;  // Display brightness (0-255)
+  uint32_t displayTimeout = 0;    // Display timeout in milliseconds
+
+  // Power configuration
+  bool deepSleepEnabled =
+      false;  // *Enabled: Is deep sleep mode currently active?
+  uint32_t deepSleepInterval = 0;  // Deep sleep interval in milliseconds
+  uint8_t batteryPercent = 0;      // Battery percentage (0-100)
+
+  // MQTT retry configuration
+  uint8_t mqttMaxRetryAttempts = 0;   // Maximum retry attempts
+  uint32_t mqttCircuitBreakerMs = 0;  // Circuit breaker timeout in milliseconds
+  bool mqttHourlyRetryEnabled =
+      false;                        // *Enabled: Is hourly retry feature active?
+  uint32_t mqttInitialRetryMs = 0;  // Initial retry delay in milliseconds
+  uint32_t mqttMaxRetryMs = 0;      // Maximum retry delay in milliseconds
+  float mqttBackoffMultiplier =
+      0.0;  // Backoff multiplier for exponential backoff
+
   StatusPackage() : BroadcastPackage(202) {}  // Type ID 202 for Alteriom status
 
   StatusPackage(JsonObject jsonObj) : BroadcastPackage(jsonObj) {
@@ -117,6 +315,69 @@ class StatusPackage : public painlessmesh::plugin::BroadcastPackage {
     firmwareVersion = jsonObj["fw"].as<TSTRING>();
     responseToCommand = jsonObj["respTo"] | 0;
     responseMessage = jsonObj["respMsg"].as<TSTRING>();
+
+    // Deserialize organization metadata (camelCase format)
+    if (jsonObj["organization"].is<JsonObject>()) {
+      JsonObject org = jsonObj["organization"];
+      organizationId = org["organizationId"].as<TSTRING>();
+      customerId = org["customerId"].as<TSTRING>();
+      deviceGroup = org["deviceGroup"].as<TSTRING>();
+      deviceName = org["device_name"].as<TSTRING>();
+      deviceLocation = org["device_location"].as<TSTRING>();
+      deviceSecretSet = org["device_secret_set"] | false;
+    }
+
+    // Deserialize sensor configuration (Build 8057 - Gateway format)
+    if (jsonObj["sensors"].is<JsonObject>()) {
+      JsonObject sensors = jsonObj["sensors"];
+      sensorReadInterval = sensors["read_interval_ms"] | 0;
+      transmissionInterval = sensors["transmission_interval_ms"] | 0;
+
+      if (sensors["calibration"].is<JsonObject>()) {
+        JsonObject calibration = sensors["calibration"];
+        tempOffset = calibration["temperature_offset"] | 0.0;
+        humidityOffset = calibration["humidity_offset"] | 0.0;
+        pressureOffset = calibration["pressure_offset"] | 0.0;
+      }
+    }
+
+    // Deserialize sensor inventory (Build 8057 - Separate key)
+    if (jsonObj["sensor_inventory"].is<JsonObject>()) {
+      JsonObject sensorInventory = jsonObj["sensor_inventory"];
+      sensorCount = sensorInventory["count"] | 0;
+      sensorTypeMask = sensorInventory["type_mask"] | 0;
+    }
+
+    // Deserialize display configuration (with backward compatibility)
+    if (jsonObj["display_config"].is<JsonObject>()) {
+      JsonObject displayConfig = jsonObj["display_config"];
+      displayEnabled = displayConfig["enabled"] | false;
+      displayBrightness = displayConfig["brightness"] | 0;
+      // Support both old and new field names for backward compatibility
+      displayTimeout =
+          displayConfig["timeout_ms"] | displayConfig["timeout"] | 0;
+    }
+
+    // Deserialize power configuration (with backward compatibility)
+    if (jsonObj["power_config"].is<JsonObject>()) {
+      JsonObject powerConfig = jsonObj["power_config"];
+      deepSleepEnabled = powerConfig["deep_sleep_enabled"] | false;
+      // Support both old and new field names for backward compatibility
+      deepSleepInterval = powerConfig["deep_sleep_interval_ms"] |
+                          powerConfig["deep_sleep_interval"] | 0;
+      batteryPercent = powerConfig["battery_percent"] | 0;
+    }
+
+    // Deserialize MQTT retry configuration
+    if (jsonObj["mqtt_retry"].is<JsonObject>()) {
+      JsonObject mqttRetry = jsonObj["mqtt_retry"];
+      mqttMaxRetryAttempts = mqttRetry["max_attempts"] | 0;
+      mqttCircuitBreakerMs = mqttRetry["circuit_breaker_ms"] | 0;
+      mqttHourlyRetryEnabled = mqttRetry["hourly_retry_enabled"] | false;
+      mqttInitialRetryMs = mqttRetry["initial_retry_ms"] | 0;
+      mqttMaxRetryMs = mqttRetry["max_retry_ms"] | 0;
+      mqttBackoffMultiplier = mqttRetry["backoff_multiplier"] | 0.0;
+    }
   }
 
   JsonObject addTo(JsonObject&& jsonObj) const {
@@ -130,13 +391,107 @@ class StatusPackage : public painlessmesh::plugin::BroadcastPackage {
       jsonObj["respTo"] = responseToCommand;
       jsonObj["respMsg"] = responseMessage;
     }
+
+    // Serialize organization metadata (mixed case per MQTT Schema v0.7.2)
+    // Always serialize to ensure predictable JSON structure
+    JsonObject org = jsonObj["organization"].to<JsonObject>();
+    org["organizationId"] = organizationId;
+    org["customerId"] = customerId;
+    org["deviceGroup"] = deviceGroup;
+    org["device_name"] = deviceName;
+    org["device_location"] = deviceLocation;
+    org["device_secret_set"] = deviceSecretSet;
+
+    // Serialize sensor configuration (Build 8057 - Match gateway format)
+    // Always serialize to ensure predictable JSON structure
+    JsonObject sensors = jsonObj["sensors"].to<JsonObject>();
+    sensors["read_interval_ms"] = sensorReadInterval;
+    sensors["read_interval_s"] = sensorReadInterval / 1000;
+    sensors["transmission_interval_ms"] = transmissionInterval;
+    sensors["transmission_interval_s"] = transmissionInterval / 1000;
+
+    // Nested calibration object - always serialize for consistency
+    JsonObject calibration = sensors["calibration"].to<JsonObject>();
+    calibration["temperature_offset"] = tempOffset;
+    calibration["humidity_offset"] = humidityOffset;
+    calibration["pressure_offset"] = pressureOffset;
+
+    // Serialize sensor inventory (Build 8057 - Separate key to avoid collision)
+    // Always serialize to ensure predictable JSON structure
+    JsonObject sensorInventory = jsonObj["sensor_inventory"].to<JsonObject>();
+    sensorInventory["count"] = sensorCount;
+    sensorInventory["type_mask"] = sensorTypeMask;
+
+    // Serialize display configuration (with both _ms and _s variants)
+    // Always serialize to ensure predictable JSON structure
+    JsonObject displayConfig = jsonObj["display_config"].to<JsonObject>();
+    displayConfig["enabled"] = displayEnabled;
+    displayConfig["brightness"] = displayBrightness;
+    displayConfig["timeout_ms"] = displayTimeout;
+    displayConfig["timeout_s"] = displayTimeout / 1000;
+
+    // Serialize power configuration (with both _ms and _s variants)
+    // Always serialize to ensure predictable JSON structure
+    JsonObject powerConfig = jsonObj["power_config"].to<JsonObject>();
+    powerConfig["deep_sleep_enabled"] = deepSleepEnabled;
+    powerConfig["deep_sleep_interval_ms"] = deepSleepInterval;
+    powerConfig["deep_sleep_interval_s"] = deepSleepInterval / 1000;
+    powerConfig["battery_percent"] = batteryPercent;
+
+    // Serialize MQTT retry configuration (with both _ms and _s variants)
+    // Always serialize to ensure predictable JSON structure
+    JsonObject mqttRetry = jsonObj["mqtt_retry"].to<JsonObject>();
+    mqttRetry["max_attempts"] = mqttMaxRetryAttempts;
+    mqttRetry["circuit_breaker_ms"] = mqttCircuitBreakerMs;
+    mqttRetry["circuit_breaker_s"] = mqttCircuitBreakerMs / 1000;
+    mqttRetry["hourly_retry_enabled"] = mqttHourlyRetryEnabled;
+    mqttRetry["initial_retry_ms"] = mqttInitialRetryMs;
+    mqttRetry["initial_retry_s"] = mqttInitialRetryMs / 1000;
+    mqttRetry["max_retry_ms"] = mqttMaxRetryMs;
+    mqttRetry["max_retry_s"] = mqttMaxRetryMs / 1000;
+    mqttRetry["backoff_multiplier"] = mqttBackoffMultiplier;
+
     return jsonObj;
   }
 
 #if ARDUINOJSON_VERSION_MAJOR < 7
   size_t jsonObjectSize() const {
-    return JSON_OBJECT_SIZE(noJsonFields + 7) + firmwareVersion.length() +
-           responseMessage.length();
+    size_t size = JSON_OBJECT_SIZE(noJsonFields + 7) +
+                  firmwareVersion.length() + responseMessage.length();
+
+    // Always add organization object size for predictable structure
+    size += JSON_OBJECT_SIZE(6) + organizationId.length() +
+            customerId.length() + deviceGroup.length() + deviceName.length() +
+            deviceLocation.length();
+
+    // Always add sensor configuration object size (Build 8057)
+    // sensors object with read_interval_ms, read_interval_s,
+    // transmission_interval_ms, transmission_interval_s, calibration
+    size += JSON_OBJECT_SIZE(5);
+    // calibration nested object - always included
+    size += JSON_OBJECT_SIZE(3);
+
+    // Always add sensor inventory object size (Build 8057)
+    size += JSON_OBJECT_SIZE(
+        2);  // sensor_inventory object with count and type_mask
+
+    // Always add display configuration object size
+    // display_config object with enabled, brightness, timeout_ms, timeout_s
+    size += JSON_OBJECT_SIZE(4);
+
+    // Always add power configuration object size
+    // power_config object with deep_sleep_enabled, deep_sleep_interval_ms,
+    // deep_sleep_interval_s, battery_percent
+    size += JSON_OBJECT_SIZE(4);
+
+    // Always add MQTT retry configuration object size
+    // mqtt_retry object with max_attempts, circuit_breaker_ms,
+    // circuit_breaker_s, hourly_retry_enabled, initial_retry_ms,
+    // initial_retry_s, max_retry_ms, max_retry_s, backoff_multiplier
+    size +=
+        JSON_OBJECT_SIZE(9) + 10;  // Extra space for backoff_multiplier string
+
+    return size;
   }
 #endif
 };

package/library.json

@@ -6,7 +6,7 @@
         "type": "git",
         "url": "https://github.com/Alteriom/painlessMesh"
     },
-    "version": "1.7.7",
+    "version": "1.7.8",
     "frameworks": ["arduino"],
     "platforms": ["espressif8266", "espressif32"],
     "srcDir": "src",

package/library.properties

@@ -1,5 +1,5 @@
 name=AlteriomPainlessMesh
-version=1.7.7
+version=1.7.8
 author=Coopdis,Scotty Franzyshen,Edwin van Leeuwen,Germán Martín,Maximilian Schwarz,Doanh Doanh,Alteriom
 maintainer=Alteriom
 sentence=A painless way to setup a mesh with ESP8266 and ESP32 devices with Alteriom extensions

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@alteriom/painlessmesh",
-  "version": "1.7.7",
+  "version": "1.7.8",
   "description": "painlessMesh is a user-friendly library for creating mesh networks with ESP8266 and ESP32 devices. This Alteriom fork includes additional packages for sensor data (SensorPackage), device commands (CommandPackage), and status monitoring (StatusPackage). It handles routing and network management automatically, so you can focus on your application. The library uses JSON-based messaging and syncs time across all nodes, making it ideal for coordinated behaviour like synchronized light displays or sensor networks reporting to a central node.",
   "keywords": [
     "arduino",