Interest in Modbus Integration for HeishaMon?

[ReinhardGruber]

Hi all,

I’ve implemented a Modbus/TCP interface in my fork of HeishaMon to enable low-level PLC / SCADA / BMS control of Panasonic Aquarea/Heisha units. Before pushing this further, I’d like to gauge interest and collect feedback from the community.

What’s included

• Modbus/TCP server exposing key telemetry and writable setpoints
  (supply/return temps, compressor state, pump duty, modes, setpoints, etc.)
• Deterministic polling/update cycle suitable for PLC logic
• Consistent register map across firmware versions

Docs: check the repo root for Modbus-Register-Mapping.md

Targeted / tested clients

• Siemens LOGO! (8.x) via Modbus/TCP client blocks
• Eaton easyE4 via Modbus/TCP (MB_CLIENT)
• Loxone via Modbus TCP client (or Modbus Extension through a TCP↔RTU gateway)
• Generic SCADA/HMI (Kepware, QModMaster, Node-RED Modbus, etc.)

Why this might help

• Direct integration into industrial PLCs and home/building automation
• Low latency, predictable behavior for control loops
• Single, stable register map instead of parsing JSON/MQTT in the PLC

Questions for you

1. Do you need Modbus? What are your use cases (PLC brand, SCADA/HMI, BMS)?
2. Register coverage: Which additional points (R/W) do you need first?
3. Safety defaults: Is the write-enable guard + range checks sufficient for you?
4. Data types: Any preference for 16-bit vs 32-bit values, scaling factors, endianness?
5. Performance: What scan/refresh rates do your PLCs typically run (ms)?

How to try it

1. Build/flash the fork and set a static IP (recommended).
2. Point your Modbus client to HOST:PORT (see firmware default).
3. Start with read-only registers to validate connectivity.
4. Enable writes and test with a non-critical setpoint first.

Call for feedback:
If you’re interested, please reply with:

• Device model + firmware version
• PLC/SCADA platform
• Must-have registers (IDs and semantics)
• Desired update rates and any constraints

If you spot mismatches between fields and the register map, please open an issue with a short capture on my fork

HeishaMonModbusTCP
Attention: only for the large board (ESP32) - check the open issues

Thanks!

[js-ed]

Good evening ,
I have started testing the new Version (4.0 Alpha ) today and I am very satisfied, because JSON query and parsing is much more complicated on a plc ( 300 byte vs 10 kbyte Json ).
The Modbus query is implemented on the smallest PLC which I have at hand (WAGO PLC 750-841, yet on CODESYS2.3) it and seems to work fine till now. The query is split into 3 Calls of 48, resp 43 registers because QModMaster sometimes showed some erros (connection lost) , the reason however is unclear.
The request delay is 5 s, timeout 200ms, which is usually largely sufficient for heating wequipment.
A second test is being set up with VTScada (Trihedral ) installed on Windows2026 server - no problems yet neither

Some open items:
Sure all values can be translated into reals when needed inside plc , however a couple of arrays of reals would be nice to have , because this avoids scaling

• Group 1 Temperatures of water circuit :Topics 1,5,6,7,9,10,,14
• Group 2 Target temperature, Topics 22,23,24,27 to 37,
• Group 3 Refrigeration cycle details Topics 8, 21,49,50,51,52,53,54,55,62.63.64, 65, 66, 67

Writing values
I think your suggestion is sufficient
The testing will be continued on the small wago plc as long as there are no serious problems

Jürgen

[js-ed]

a small flaw
scaling of some temperatures by a factor of 0.01 is ok, but I observed return temperature being at 32°C exactly , then only 32 instead of 3200 has been transmitted by the Modbus - hence PLC cvalculates 0.32 °C
Jürgen

[js-ed]

Hi,
in my opinion it would be better to scale all temperatures consistently to 0.01 K even if the decimals are of no meaning bcease the Heisha already rounds them off
Jürgen

[js-ed]

Hi Reini
attached two screenshots
One showing the raw data received via MODBUS showing topic 5 = 31 and topic6 =3425 ,
the second screenshot shows the data from Heishamon web page showing topic5 = 31°C and topic 6=34.25°C
I believe there is a tranlation error somewhere between MQTT // Json and the Modbus Program
Jürgen

[ReinhardGruber]

Hi Jürgen,

thanks for the detailed findings and the screenshots. You’re right: some topics are shown with decimals in the web UI, while the Modbus layer currently mixes “plain °C” (e.g., 32) with “scaled x100” (e.g., 3425). That inconsistency is exactly what bit you on the PLC (31 → 0.31 °C vs 31.00 °C expected).

HeishaMon grew organically over time; data structures are scattered and need a cleanup. I agree that fixing this consistently at the source (in HeishaMon) is the only sensible way—otherwise every fork and every client will keep tripping over edge cases.

As a short-term measure I’ll add a quick-and-dirty fix: enforce x100 scaling for all temperatures across the Modbus map so PLCs see consistent values immediately. Mid-/long-term, the structure should be refactored and the scaling standardized upstream in HeishaMon to make this robust and permanent.

Reini

[ReinhardGruber]

ReinhardGruber@1364cb6

[jtronics]

for your info ...
salakrzy https://github.com/salakrzy/HeishaMonBoth is working on a RS485 Modbus integration for up to 4 devices.
Version 3.9 supports meters with MODBUS interface

[ReinhardGruber]

Please open any additional requirements or bug descriptions as issues in my fork.
https://github.com/ReinhardGruber/HeishaMonModbusTCP/issues

[js-ed]

Hi Reini Checking ver 4.01 now You are absolutly right – but who has not gone through this step in his life. A unique data format for all measured values throughout the entire program °C x 100 for all measured Temperature values and settings which is commonly used in many systems as it allows to store and transmit all common Temp. Measurments as integers. kPa for pressure kpf/ cm² * 100 is not exactly but close to 0.01 kpf/cm² = 0.980655 kPa is also very practical and common as it matches with the precision of transmitters in most applications Other alternative : All phyiscal values transformed into reals ( 4 Bit) For SET commands this would be a nice feature but it is much less important now. Regards Jürgen Von: ReinhardGruber ***@***.***> Gesendet: Mittwoch, 5. November 2025 09:39 An: Egyras/HeishaMon ***@***.***> Cc: js-ed ***@***.***>; Comment ***@***.***> Betreff: Re: [Egyras/HeishaMon] Interest in Modbus Integration for HeishaMon? (Discussion #740) Hi Jürgen, thanks for the detailed findings and the screenshots. You’re right: some topics are shown with decimals in the web UI, while the Modbus layer currently mixes “plain °C” (e.g., 32) with “scaled x100” (e.g., 3425). That inconsistency is exactly what bit you on the PLC (31 → 0.31 °C vs 31.00 °C expected). HeishaMon grew organically over time; data structures are scattered and need a cleanup. I agree that fixing this consistently at the source (in HeishaMon) is the only sensible way—otherwise every fork and every client will keep tripping over edge cases. As a short-term measure I’ll add a quick-and-dirty fix: enforce x100 scaling for all temperatures across the Modbus map so PLCs see consistent values immediately. Mid-/long-term, the structure should be refactored and the scaling standardized upstream in HeishaMon to make this robust and permanent. Reini — Reply to this email directly, view it on GitHub<#740 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BNCYOVUZV5GDPDD63XYGWP333GZRBAVCNFSM6AAAAACLAQKRHWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIOBXHAZTAMQ>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>

[js-ed]

Problem is persistent Von: ReinhardGruber ***@***.***> Gesendet: Mittwoch, 5. November 2025 09:39 An: Egyras/HeishaMon ***@***.***> Cc: js-ed ***@***.***>; Comment ***@***.***> Betreff: Re: [Egyras/HeishaMon] Interest in Modbus Integration for HeishaMon? (Discussion #740) Hi Jürgen, thanks for the detailed findings and the screenshots. You’re right: some topics are shown with decimals in the web UI, while the Modbus layer currently mixes “plain °C” (e.g., 32) with “scaled x100” (e.g., 3425). That inconsistency is exactly what bit you on the PLC (31 → 0.31 °C vs 31.00 °C expected). HeishaMon grew organically over time; data structures are scattered and need a cleanup. I agree that fixing this consistently at the source (in HeishaMon) is the only sensible way—otherwise every fork and every client will keep tripping over edge cases. As a short-term measure I’ll add a quick-and-dirty fix: enforce x100 scaling for all temperatures across the Modbus map so PLCs see consistent values immediately. Mid-/long-term, the structure should be refactored and the scaling standardized upstream in HeishaMon to make this robust and permanent. Reini — Reply to this email directly, view it on GitHub<#740 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BNCYOVUZV5GDPDD63XYGWP333GZRBAVCNFSM6AAAAACLAQKRHWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIOBXHAZTAMQ>. You are receiving this because you commented.Message ID: ***@***.******@***.***>>

[ReinhardGruber]

v4.01 Alpha Loxone: Topic 5 and 6 [cid:8d864d41-2e3d-44a0-b4a8-fd04c268a163] i have only changed ModBus (Webview is untouched) Please open any additional requirements or bug descriptions as issues in my fork. https://github.com/ReinhardGruber/HeishaMonModbusTCP/issues

…

________________________________ Von: js-ed ***@***.***> Gesendet: Mittwoch, 05. November 2025 16:54 Bis: Egyras/HeishaMon ***@***.***> Cc: Gruber Reinhard ***@***.***>; Author ***@***.***> Betreff: Re: [Egyras/HeishaMon] Interest in Modbus Integration for HeishaMon? (Discussion #740) Problem is persistent Von: ReinhardGruber ***@***.***> Gesendet: Mittwoch, 5. November 2025 09:39 An: Egyras/HeishaMon ***@***.***> Cc: js-ed ***@***.***>; Comment ***@***.***> Betreff: Re: [Egyras/HeishaMon] Interest in Modbus Integration for HeishaMon? (Discussion #740) Hi Jürgen, thanks for the detailed findings and the screenshots. You’re right: some topics are shown with decimals in the web UI, while the Modbus layer currently mixes “plain °C” (e.g., 32) with “scaled x100” (e.g., 3425). That inconsistency is exactly what bit you on the PLC (31 → 0.31 °C vs 31.00 °C expected). HeishaMon grew organically over time; data structures are scattered and need a cleanup. I agree that fixing this consistently at the source (in HeishaMon) is the only sensible way―otherwise every fork and every client will keep tripping over edge cases. As a short-term measure I’ll add a quick-and-dirty fix: enforce x100 scaling for all temperatures across the Modbus map so PLCs see consistent values immediately. Mid-/long-term, the structure should be refactored and the scaling standardized upstream in HeishaMon to make this robust and permanent. Reini ― Reply to this email directly, view it on GitHub<#740 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BNCYOVUZV5GDPDD63XYGWP333GZRBAVCNFSM6AAAAACLAQKRHWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIOBXHAZTAMQ>. You are receiving this because you commented.Message ID: ***@***.******@***.***>> ― Reply to this email directly, view it on GitHub<#740 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAX5JPOZS6RJ7PCQZM4LPFT33IMSZAVCNFSM6AAAAACLAQKRHWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIOBYGI3DKMA>. You are receiving this because you authored the thread.Message ID: ***@***.***>