v2.0.0-beta.5

Hitachi Yutaki – Separate Heating/Cooling Sensors & Critical Fixes (v2.0.0-beta.5)

This release introduces separate thermal energy sensors for heating and cooling, providing accurate energy tracking and fixing critical setup issues. This is a breaking change that improves COP calculation accuracy by filtering defrost cycles and properly separating heating from cooling operations.

✨ What's New?

• Separate Thermal Energy Sensors: The integration now provides explicit sensors for heating and cooling operations:

  • Real-time Power:
    • thermal_power_heating: Heating power output (when ΔT > 0) in kW
    • thermal_power_cooling: Cooling power output (when ΔT < 0) in kW - only created for units with cooling circuits
  • Daily Energy (auto-reset at midnight):
    • thermal_energy_heating_daily: Daily heating energy production in kWh
    • thermal_energy_cooling_daily: Daily cooling energy production in kWh - cooling circuits only
  • Total Cumulative Energy:
    • thermal_energy_heating_total: Total heating energy production in kWh
    • thermal_energy_cooling_total: Total cooling energy production in kWh - cooling circuits only

• Improved Thermal Energy Calculation Logic: Fixes issue #123 with a complete rewrite of the thermal energy calculation:

  • Heating/Cooling Separation: Now correctly separates heating (ΔT > 0) from cooling (ΔT < 0) operations
  • Defrost Cycle Filtering: Defrost cycles are now filtered and not counted as energy production, eliminating false cooling energy measurements
  • Compressor-Based Measurement: Only measures energy produced by the heat pump when the compressor is running
  • Universal Logic: Works automatically for heating circuits, DHW, and pool based on water temperature delta
  • Accurate COP Calculations: This results in accurate COP calculations (previously inflated by counting defrost as production)

• Recorder Dependency: Added recorder dependency to manifest for proper Home Assistant validation and to ensure compatibility with data rehydration features.

🔧 Bug Fixes

• Setup Failure Fix: Fixed setup failure when configuration parameters are missing by adding the required translation_key parameter to async_create_issue and corresponding translations. This resolves issue #146 where the integration would fail to create repair issues during configuration.

• Hassfest Validation Fix: Fixed hassfest validation error by adding missing recorder dependency to manifest. This ensures the integration passes all Home Assistant validation checks.

⚠️ Breaking Changes

• Thermal Energy Sensor Migration Required: The old thermal energy sensors are now deprecated (disabled by default, but still available for backward compatibility):
  • thermal_power → use thermal_power_heating instead
  • daily_thermal_energy → use thermal_energy_heating_daily instead
  • total_thermal_energy → use thermal_energy_heating_total instead
  • Action Required: Update your Energy Dashboard configurations and automations to use the new sensor names
  • Why Deprecated: The old sensors counted defrost cycles and lacked heating/cooling separation, resulting in incorrect COP values

📚 Technical Improvements

• ThermalPowerService Enhancement: New service implementation with separate heating and cooling power tracking:

  • Automatic mode detection based on temperature delta (ΔT)
  • Defrost cycle filtering to prevent false measurements
  • Compressor state validation before energy calculation
  • Universal logic applicable to all thermal circuits (heating, DHW, pool, cooling)

• ThermalEnergyAccumulator Updates: Enhanced accumulator with separate tracking for heating and cooling:

  • Independent energy counters for heating and cooling modes
  • Proper state restoration after Home Assistant restarts
  • Daily reset logic for daily energy sensors

• Sensor Entity Builder: Updated thermal sensor builder to conditionally create cooling sensors only when cooling circuits are detected, reducing unnecessary entities for heating-only installations.

• Improved Measurement Accuracy: The new calculation logic ensures:

  • Only real energy production is measured (compressor must be running)
  • Defrost cycles don't inflate energy production values
  • Heating and cooling are properly separated for accurate tracking
  • COP calculations reflect true heat pump performance

📝 Important Notes

• Migration Required: After upgrading to this version, you must update your Energy Dashboard and any automations that reference the old thermal energy sensors:

  • Replace thermal_power with thermal_power_heating
  • Replace daily_thermal_energy with thermal_energy_heating_daily
  • Replace total_thermal_energy with thermal_energy_heating_total
  • If you have cooling circuits, add the new cooling sensors to your dashboard

• COP Accuracy Improvement: The filtering of defrost cycles means your COP values may change compared to previous versions. This is expected and reflects more accurate performance measurements.

• Cooling Sensor Availability: Cooling sensors (thermal_power_cooling, thermal_energy_cooling_daily, thermal_energy_cooling_total) are only created for units that have cooling circuits configured. If you don't see these sensors, your unit may not support cooling mode.

• Backward Compatibility: The old sensors remain available (disabled by default) for a transition period, but they will be removed in a future release. Please migrate to the new sensors as soon as possible.

• Recorder Dependency: This release requires Home Assistant's Recorder to be enabled for proper operation of data rehydration features (introduced in beta.4).

🧪 Testing Needed

We would appreciate feedback on:

• Sensor Migration: Verify that the new heating/cooling sensors appear correctly and provide accurate measurements.

• Energy Dashboard: Confirm that your Energy Dashboard continues to work after migrating to the new sensor names.

• COP Accuracy: Check that COP values are now more accurate and don't show inflated values during defrost cycles.

• Cooling Circuits: If you have cooling circuits, verify that cooling sensors are created and track cooling energy correctly.

• Setup Process: Test the setup/configuration flow to ensure the translation_key fix resolves setup failures.

• Defrost Filtering: Monitor during defrost cycles to confirm that energy production is correctly paused (not counted).

🐛 Bug Reports

If you encounter any issues, please open a GitHub issue and include:

• Your Home Assistant version.
• Your configuration (heat pump model, gateway type, cooling circuits if configured).
• Debug-level logs (especially for thermal energy calculations and sensor creation).
• A clear description of the problem and reproduction steps.
• Information about whether you've migrated from the old sensors to the new ones.

🙏 Acknowledgments

Thanks to the community for their feedback and contributions:

• Special Thanks: A special thank you to @Neuvidor for their investigation and contributions around COP calculation and thermal energy measurement, which were instrumental in improving the accuracy of these features.

• Issues Resolved:

  • #123 - Thermal energy calculation improvements
  • #146 - Setup failure fix

• Beta Testers: Thank you to all testers providing feedback on the v2.0.0-beta releases.

v2.0.0-beta.4

Hitachi Yutaki – Data Rehydration & Temperature Fixes (v2.0.0-beta.4)

This release introduces automatic data rehydration from Home Assistant's Recorder, eliminating data loss after restarts, and fixes critical temperature unit issues for DHW and anti-legionella settings.

✨ What's New?

• Recorder-Based Data Rehydration: COP and compressor timing sensors now automatically reconstruct their historical data from Home Assistant's Recorder on startup. This eliminates data loss after Home Assistant restarts and ensures continuity of performance measurements. The integration leverages existing sensor history instead of maintaining separate persistent storage, ensuring consistency with Home Assistant's historical data.

• Smart Entity Resolution: The rehydration system intelligently resolves required sensor entities using a preference order:

  1. User-provided entities (configured via options)
  2. Built-in sensors registered by this integration (via entity registry lookup)

• Improved Measurement Sorting: Fixed negative time span values in COP calculations by ensuring measurements are sorted chronologically before calculating measurement periods and energy integration.

🔧 Bug Fixes

• DHW Temperature Unit Fix: Fixed Domestic Hot Water target temperature to be expressed in °C instead of tenths of degrees. This ensures correct temperature values are displayed and set in Home Assistant.

• Anti-legionella Temperature Unit Fix: Fixed anti-legionella cycle temperature to be expressed in °C instead of tenths of degrees, ensuring accurate temperature settings for the anti-legionella cycle.

• Translation Validation Fix: Removed invalid 'repair' section from translation files (en.json and fr.json) that was causing hassfest validation errors. The integration now uses standard Home Assistant issue creation without custom translations.

📚 Technical Improvements

• Enhanced COP Service: Added bulk_load() method to EnergyAccumulator for efficient loading of historical measurements during rehydration. Improved measurement pruning logic with dedicated _prune_old_measurements() method.

• Recorder Rehydration Module: New recorder_rehydrate.py adapter module providing:

  • async_replay_cop_history(): Reconstructs power measurements from Recorder sensor history
  • async_replay_compressor_states(): Rebuilds compressor timing cycles from historical data
  • Intelligent timeline reconstruction with proper state parsing and validation

• Sensor Entity Enhancements: Extended HitachiYutakiSensor with rehydration hooks:

  • _async_rehydrate_cop_history(): Rebuilds COP measurement buffer on startup
  • _async_rehydrate_compressor_history(): Restores compressor timing cycles
  • _async_build_cop_entity_map(): Resolves required entity IDs for rehydration

• Improved Error Handling: Rehydration failures are gracefully handled with detailed logging, ensuring the integration continues to function even if historical data cannot be reconstructed.

📝 Important Notes

• Data Continuity: After upgrading to this version, COP and compressor timing sensors will automatically rebuild their historical data from Home Assistant's Recorder on the next startup. This process is transparent and requires no user intervention.

• Storage Strategy: The integration now relies on Home Assistant's Recorder history instead of custom persistent storage for COP and compressor timing data. This eliminates redundant data storage and ensures consistency with Home Assistant's historical data.

• Temperature Settings: Users who have previously configured DHW or anti-legionella temperatures may need to verify their settings after this update, as the temperature values are now correctly interpreted in °C.

• Backward Compatibility: Existing configurations continue to work without changes. The rehydration system automatically detects and uses configured external entities when available.

🧪 Testing Needed

We would appreciate feedback on:

• Data Rehydration: Verify that COP and compressor timing sensors correctly restore their historical data after Home Assistant restarts.

• Temperature Settings: Confirm that DHW and anti-legionella temperature values are now correctly displayed and can be set properly.

• Entity Resolution: Test that the rehydration system correctly resolves required sensor entities, especially when using external temperature or power sensors.

• Performance: Verify that the rehydration process doesn't significantly impact startup time, especially for installations with extensive historical data.

🐛 Bug Reports

If you encounter any issues, please open a GitHub issue and include:

• Your Home Assistant version.
• Your configuration (heat pump model, gateway type, external sensor entities if configured).
• Debug-level logs (especially for rehydration process and entity resolution).
• A clear description of the problem and reproduction steps.

🚀 Future Benefits

• Zero Data Loss: Historical performance data is preserved across Home Assistant restarts.

• Consistency: Single source of truth for historical data (Home Assistant's Recorder).

• Reduced Storage Overhead: No need for separate persistent storage mechanisms.

• Better User Experience: Accurate temperature values for all DHW and anti-legionella settings.

Thanks for helping test this release that improves data persistence and fixes critical temperature unit issues!

v1.9.4

Hitachi Yutaki – Robust Modbus Reconnection Handling (v1.9.4)

A new release of the Hitachi Yutaki integration focused on improving reliability and stability when dealing with network interruptions and Modbus gateway connectivity issues.

✨ What's New?

• Robust Modbus Reconnection Handling: The integration now gracefully handles network disconnects and automatically recovers connectivity with intelligent retry logic:
  • Automatic connection recovery with exponential backoff (up to 3 retry attempts)
  • Proper cleanup and reset of stale connections before reconnecting
  • Enhanced error handling and logging for connection attempts
  • Ensures all entities properly recover once the connection is restored after network interruptions
  • Prevents integration crashes or unexpected behavior during network outages
• Improved Connection State Management: The Modbus client connection handling has been completely refactored using asyncio, providing more reliable connection state tracking and recovery mechanisms.
• Better Error Recovery: Connection errors now trigger automatic connection cleanup and reset, preventing stuck states and ensuring fresh connection attempts.

🔧 Maintenance Updates

• Development Tools:
  • Bump colorlog from 6.9.0 to 6.10.1 (#120)
  • Bump ruff from 0.13.3 to 0.14.2 (#126)
  • Bump pip requirement from <25.3,>=21.0 to >=21.0,<25.4 (#127)

📝 Important Notes

• No breaking changes; existing setups continue to work seamlessly.
• This release addresses connectivity issues that could occur after network interruptions or Modbus gateway disconnections.
• The integration will now automatically retry failed connections with exponential backoff, improving resilience in unstable network environments.
• Users experiencing reconnection problems should see significant improvements in stability.

🧪 Testing Needed

We would appreciate feedback on:

• Connection Recovery: Verify that the integration properly recovers after temporary network interruptions (router restart, network cable unplugged/replugged, WiFi disconnection).
• Gateway Reconnection: Test behavior when the Modbus gateway is temporarily unavailable or powered off/on.
• Entity State Management: Confirm that all entities correctly transition to unavailable during connection failures and back to normal state once connectivity is restored.
• Retry Behavior: Observe the retry mechanism during prolonged network outages (should retry up to 3 times with exponential backoff).

🐛 Bug Reports

If you encounter any issues, please open a GitHub issue and include:

• Your Home Assistant version.
• Your configuration (heat pump model, gateway type, network setup).
• Debug-level logs showing connection attempts and retry behavior.
• A clear description of the problem, including:
  • When the issue occurs (startup, during operation, after network interruption).
  • Duration of network interruptions before issues appear.
  • Whether entities recover correctly after connectivity is restored.
• Network environment details (WiFi, wired, router model if relevant).

Thanks for helping improve the reliability and resilience of the Hitachi Yutaki integration!

Hitachi Yutaki – Complete Architectural Overhaul (v2.0.0-beta.3)

Hitachi Yutaki – Complete Architectural Overhaul (v2.0.0-beta.3)

A major architectural release implementing hexagonal architecture and domain-driven design, with robust Modbus connection recovery and comprehensive business API abstraction.

✨ What's New?

• Robust Modbus Connection Recovery: Automatic reconnection with exponential backoff (1s, 2s, 4s intervals) and transparent recovery without Home Assistant restart. Fixes issue #118 where the integration failed to recover from temporary network interruptions.
• Complete Hexagonal Architecture: Pure business logic in domain layer (100% testable without Home Assistant mocks), adapters bridging domain with HA, and domain-driven entity organization.
• Domain-Driven Entity Structure: Entities organized by business domains (circuit, compressor, control_unit, dhw, gateway, hydraulic, performance, pool, power, thermal) instead of technical grouping.
• Comprehensive Business API: HitachiApiClient with typed methods for all controllable parameters, eliminating direct Modbus access from entities and providing natural data types (float for temperatures, bool for settings).
• Builder Pattern Implementation: Type-safe entity creation with conditional logic based on device capabilities, replacing direct entity instantiation.
• Platform Orchestrators: Simplified platform files acting as pure orchestrators, importing and calling domain builders.
• Enhanced Modularity: Each domain is self-contained with its own sensors, switches, numbers, etc., improving maintainability and scalability.

🔧 Technical Improvements

• Data Conversion Enhancements: Centralized deserialization logic with pattern-based naming (convert_from_tenths, convert_signed_16bit, convert_pressure) and fixed sensor readings for secondary compressor current and pressure sensors.
• Modbus Register Organization: Logical device grouping (gateway, control_unit, primary_compressor, secondary_compressor, circuit_1, circuit_2, dhw, pool) for improved clarity and maintainability.
• Entity Identifier Updates: Renamed r134a_ to secondary_compressor_ for better readability, enhanced alarm sensor to display descriptions as state with numeric codes as attributes.
• Code Quality: Reduced sensor.py from 1657 to ~150 lines, eliminated code duplication, simplified import structure with clear domain boundaries.

📚 Documentation & Architecture

• Specialized Documentation: New README files for each architectural layer:
  • Domain Layer: Pure business logic
  • Adapters Layer: Infrastructure implementations
  • Entities Layer: Domain-driven organization
• Updated Main README: Reflects new architecture and project structure
• Comprehensive CHANGELOG: Detailed migration notes and technical improvements

📝 Important Notes

• Breaking Changes: This is a major architectural refactoring. While user-facing functionality remains the same, developers should review the new architecture documentation before contributing.
• Backward Compatibility: Existing configurations continue to work without changes.
• Migration Guide: See specialized README files in domain/, adapters/, and entities/ directories for detailed architectural information.
• Future-Ready: Architecture prepared for HTTP-based gateways and persistent storage solutions.

🧪 Testing Needed

We would appreciate feedback on:

• Connection Recovery: Test behavior during network interruptions and verify automatic reconnection works correctly.
• Entity Functionality: Confirm all existing entities work as expected with the new architecture.
• Performance: Verify that the new architecture doesn't impact response times or resource usage.
• Configuration: Test that existing configurations load correctly and all settings are preserved.

🐛 Bug Reports

If you encounter any issues, please open a GitHub issue and include:

• Your Home Assistant version.
• Your configuration (heat pump model, gateway type).
• Debug-level logs (especially for connection recovery and entity creation).
• A clear description of the problem and reproduction steps.

🚀 Future Benefits

• Enhanced Testability: Domain layer is 100% testable without Home Assistant mocks.
• Improved Maintainability: Business logic centralized in domain layer, single point of truth for calculations.
• Better Extensibility: Easy to add new entity types, gateways, or storage implementations.
• Cleaner Architecture: Clear separation between business logic and infrastructure concerns.

Thanks for helping test this major architectural improvement that positions the Hitachi Yutaki integration for future growth and maintainability!

v1.9.3

Hitachi Yutaki – Robust COP Validation and Unit Detection (v1.9.3)

A new release of the Hitachi Yutaki integration focused on reliability and data integrity for COP calculations, with improved options flow compatibility and maintenance updates.

✨ What's New?

• Comprehensive COP Data Validation: Strong validation for input ranges to prevent aberrant values:
  • Temperatures: -10°C to 80°C
  • Water flow: 0.1 to 10.0 m³/h
  • ΔT: 0.5 to 30 K
  • Thermal power: 0.1 to 50.0 kW
  • Electrical power: 0.1 to 20.0 kW
  • Final COP: 0.5 to 8.0
• Intelligent Power Unit Detection: Automatic handling of W vs kW using the entity unit_of_measurement, with robust fallback based on realistic value ranges.
• Energy Accumulation for COP: COP is computed over time using integrated energy, improving stability and accuracy.
• Options Flow Reliability (Fix #109): Avoid providing default=None to entity selectors to prevent the UI error “Entity None is neither a valid entity ID nor a valid UUID”, and stop storing the config_entry on the options flow instance to comply with Home Assistant’s deprecation (will become an error in 2025.12). See #109.
• Better Logging: Enhanced debug logs for unit detection, validation failures, and COP computation.

🔧 Maintenance Updates

• CI/CD Pipeline: Update actions/setup-python to v6
• Development Tools: Bump ruff to 0.13.3

📝 Important Notes

• No breaking changes; existing setups continue to work.
• The integration now rejects invalid data instead of returning misleading COP values.
• Seamless support for both W and kW power sensors.
• Options flow changes address the problem reported in #109.

🧪 Testing Needed

We would appreciate feedback on:

• COP stability with realistic inputs (temperature, water flow, power) across different operating states (heating, cooling, DHW, pool).
• Automatic unit detection for power sensors (W vs kW), especially when unit_of_measurement is present vs missing.
• Options flow: confirm the UI opens without errors and that settings save correctly.

🐛 Bug Reports

If you encounter any issues, please open a GitHub issue and include:

• Your Home Assistant version.
• Your configuration (heat pump model, gateway type).
• Debug-level logs (for COP/unit detection/validation).
• A clear description of the problem and reproduction steps.

Thanks for helping improve the reliability and observability of COP calculations in the Hitachi Yutaki integration!

v1.9.3-beta.1

Hitachi Yutaki – COP Calculation Fixes & Data Validation (v1.9.3-beta.1)

A new beta release of the Hitachi Yutaki integration is now available, featuring major improvements to COP (Coefficient of Performance) calculations and robust data validation to eliminate aberrant values.

✨ What's New?

• Fixed Aberrant COP Values: Resolved the issue where COP sensors were returning impossible values (50-500) by implementing comprehensive data validation and intelligent unit detection.
• Intelligent Power Unit Detection: The integration now automatically detects whether your power sensors report values in watts (W) or kilowatts (kW) using the unit_of_measurement attribute, with intelligent fallback detection.
• Comprehensive Data Validation: Added robust validation for all input parameters:
  • Temperature ranges (-10°C to 80°C)
  • Water flow rates (0.1 to 10.0 m³/h)
  • Temperature differences (0.5 to 30 K)
  • Power ranges (0.1 to 50.0 kW thermal, 0.1 to 20.0 kW electrical)
  • Final COP values (0.5 to 8.0)
• Enhanced Debug Logging: Detailed logging for unit detection, validation failures, and COP calculations to help diagnose issues.
• Energy Accumulation Validation: Added validation for accumulated thermal and electrical energies to prevent calculation errors.

🔧 Technical Improvements

• Automatic Unit Conversion: Seamless handling of power sensors in both W and kW units
• Range-Based Fallback: Intelligent detection when unit_of_measurement is not available
• Validation Pipeline: Multi-layer validation ensures only reasonable values are used in COP calculations
• Error Handling: Graceful rejection of invalid data with detailed logging

📝 Important Notes

• This update is completely backward compatible - no configuration changes are required.
• The integration now provides much more realistic COP values (typically 2-6 for heat pumps).
• Invalid or aberrant data will be rejected with warning logs instead of producing incorrect COP values.
• External power and voltage sensors are now better supported with automatic unit detection.

🧪 Testing Needed

We would appreciate feedback on:

• COP Values: Are your COP readings now within reasonable ranges (2-6)?
• Power Sensors: Does the integration correctly detect your power sensor units (W vs kW)?
• Data Validation: Are you seeing appropriate warning logs for invalid data?
• Performance: Any impact on integration performance with the additional validations?

🐛 Bug Reports

If you encounter any issues, please open a GitHub issue and include:

• Your Home Assistant version
• Your power sensor configuration (unit of measurement)
• Debug mode logs showing validation messages
• Current COP values and whether they seem realistic
• A clear description of the problem

🔍 Debugging

To help diagnose COP calculation issues, enable debug logging:

logger:
  logs:
    custom_components.hitachi_yutaki: debug

This will show detailed information about unit detection, data validation, and COP calculations.

This beta release addresses the COP calculation issues and provides a foundation for more reliable performance monitoring of your Hitachi Yutaki heat pump system.

v1.9.2

Hitachi Yutaki – Universal pymodbus Compatibility (v1.9.2)

A new release of the Hitachi Yutaki integration is now available, ensuring seamless compatibility with all Home Assistant versions, including the latest 2025.9.0+.

✨ What's New?

• Universal pymodbus Compatibility: The integration now automatically detects your pymodbus version and uses the correct parameter names. This ensures compatibility with both older Home Assistant versions (pymodbus < 3.10.0) and the latest versions (pymodbus >= 3.10.0).
• Future-Proof Design: The automatic version detection means the integration will continue working even if future pymodbus updates introduce API changes.
• Seamless Upgrades: Users upgrading to Home Assistant 2025.9.0+ will experience no disruption - the integration continues to work exactly as before.

🔧 Maintenance Updates

• Development Tools: Updated Ruff linter from 0.12.4 to 0.12.10 for improved code quality checks
• CI/CD Pipeline: Updated GitHub Actions checkout from v4 to v5 for better reliability
• Pre-commit Hooks: Updated pre-commit from 4.2.0 to 4.3.0 for enhanced development workflow
• Build Tools: Updated pip requirement constraints for better dependency management

📝 Important Notes

• This update is completely backward compatible - no configuration changes are required.
• The integration automatically detects whether to use slave (older pymodbus) or device_id (newer pymodbus) parameters.
• All existing functionality remains unchanged - this is purely a compatibility enhancement.

🧪 Testing Needed

We would appreciate feedback on:

• Users upgrading from HA 2025.8 to HA 2025.9.0+: Does the integration continue working without any issues?
• Users on older HA versions: Is there any change in behavior or performance?

🐛 Bug Reports

If you encounter any issues, please open a GitHub issue and include:

• Your Home Assistant version.
• Your configuration (heat pump model, gateway type).
• Debug mode logs.
• A clear description of the problem.

This release resolves the compatibility issue reported in #97 and ensures the Hitachi Yutaki integration works reliably across all supported Home Assistant versions.

v1.9.2-beta.1

Hitachi Yutaki – Universal pymodbus Compatibility (v1.9.2-beta.1)

A new release of the Hitachi Yutaki integration is now available, ensuring seamless compatibility with all Home Assistant versions, including the latest 2025.9.0+.

✨ What's New?

• Universal pymodbus Compatibility: The integration now automatically detects your pymodbus version and uses the correct parameter names. This ensures compatibility with both older Home Assistant versions (pymodbus < 3.10.0) and the latest versions (pymodbus >= 3.10.0).
• Future-Proof Design: The automatic version detection means the integration will continue working even if future pymodbus updates introduce API changes.
• Seamless Upgrades: Users upgrading to Home Assistant 2025.9.0+ will experience no disruption - the integration continues to work exactly as before.

📝 Important Notes

• This update is completely backward compatible - no configuration changes are required.
• The integration automatically detects whether to use slave (older pymodbus) or device_id (newer pymodbus) parameters.
• All existing functionality remains unchanged - this is purely a compatibility enhancement.

🧪 Testing Needed

We would appreciate feedback on:

• Users upgrading from HA 2025.8 to HA 2025.9.0+: Does the integration continue working without any issues?
• Users on older HA versions: Is there any change in behavior or performance?

🐛 Bug Reports

If you encounter any issues, please open a GitHub issue and include:

• Your Home Assistant version.
• Your configuration (heat pump model, gateway type).
• Debug mode logs.
• A clear description of the problem.

This release resolves the compatibility issue reported in #97 and ensures the Hitachi Yutaki integration works reliably across all supported Home Assistant versions.

v2.0.0-beta.2

Hitachi Heat Pump – PyModbus Compatibility & Integration Rename (v2.0.0-beta.2)

This pre-release adds robust PyModbus version compatibility and renames the integration to better reflect its broader scope beyond the Yutaki product line.

✨ What's New?

• PyModbus Version Compatibility: The integration now works seamlessly with both PyModbus 3.9.2 (current Home Assistant) and 3.11.1+ (Home Assistant 2025.9.0+). A compatibility shim automatically detects the correct device addressing parameter (slave vs device_id) at runtime.
• Integration Rename: The integration is now called "Hitachi Heat Pump" instead of "Hitachi Yutaki" to better represent its support for the broader Hitachi heat pump product line, including Yutaki and Yutampo models.
• Backward Compatibility: Existing configurations continue to work without any changes. The rename is purely cosmetic and doesn't affect functionality.

🔧 Technical Improvements

• Smart Parameter Detection: The new ModbusClientShim automatically detects whether your PyModbus version uses slave, device_id, or unit parameters and adapts accordingly.
• Future-Proof Architecture: The compatibility layer ensures the integration will work with future PyModbus versions without requiring code changes.
• Clean Separation: Device addressing logic is now centralized in a dedicated compatibility module, making the codebase more maintainable.

📝 Important Notes

• No Configuration Changes Required: Your existing setup will continue to work exactly as before. The integration rename is purely cosmetic.
• PyModbus Compatibility: The integration now supports the full range of PyModbus versions used by Home Assistant, from 3.9.2 to 3.11.1+.
• Beta Status: This remains a beta release as we continue refining the hexagonal architecture introduced in 2.0.0-beta.1.

🧪 Testing Needed

We would appreciate feedback on:

• PyModbus Compatibility: Does the integration work correctly with your current Home Assistant version (3.9.2) and can you test with newer versions if available?
• Integration Rename: Is the new "Hitachi Heat Pump" name more appropriate and clear?
• General Functionality: Do all features continue to work as expected after the compatibility layer changes?

🐛 Bug Reports

If you encounter any issues, please open a GitHub issue and include:

• Your Home Assistant version and PyModbus version (if known).
• Your configuration (heat pump model, gateway type).
• Debug mode logs if possible.
• A clear description of the problem and reproduction steps.