Thanks for the detailed comparison—this is very useful.
Some readings are clearly incorrect. The huge current values suggest a word-order or address-alignment issue, which the raw debug log should help us pinpoint. I also found that our BE1/BE3 labels were reversed and have corrected those.
Could you check whether “word swap” is enabled in menu 5.3.11? The nibegw-esp setup instructions require it. Just let me know its current setting first.
What devices do you have? Main, Heating, Hot Water?
Solar shouldn’t be recommended without evidence that it’s installed, so I’ll investigate that detection too. The fan reading also needs checking: our Modbus reference describes that register as a percentage, whereas your API export describes it as a fan mode.
Please send the debug log and diagnostic report after the hot-water cycle, as planned, with approximate start/stop times. Leave writes disabled for now, and treat the beta’s power and energy figures as unverified.
One small clarification: the 122 shown during detection means 61 parameters checked twice.
Thanks again—this gives us concrete issues to work through.
“Word swap” is enabled in menu 5.3.11.
It has been enabled from the start, and I do get values via the QModMaster terminal when I send individual register queries.
So, I believe we have the correct values from the respective registers.
The question is simply? which register addresses are the correct ones for Modbus:
Are they the ones in the F730.json file?
Or the ones I dumped from my F730 via the MyUplink API?
Or is it neither of these, or perhaps a mix?
Regarding fan speed: in the API, it is 50221. As mentioned earlier, I cannot access register addresses above 50000 via Modbus. I have therefore tried to find the fan speed in one of the registers listed as “current fan speed” in the F730.JSON file—I know the fan speed is 85%. The only register that returns a value of 85 is 47265, but I don’t think this represents the actual speed; rather, it seems to be the value set on the heat pump for “Normal” speed—in other words, just a setting.
I’m happy to run register queries via QModMaster if you need me to!
In any case, I took screenshots of the installation and put them in this document: Microsoft OneDrive
You can also see the four devices I currently have there.
I took a closer look at a few registers that are easy to verify. I found the following:
Main: Liquid line (BT15) seems to show BT16
Main: Discharge (BT14) seems to show BT15
HW: Hot water top (BT7) seems to show BT6
Heating: Heating return (BT3) seems to show BT7
Heating: Extract air (BT20) seems to show BT21
Could it simply be an offset error in the register addresses? In other words, if you want to query 40025 (BT20), the Modbus address should be 24. If you query address 25, you get the response for BT21 (40026) because that happens to be the one located there. Just a thought…
Your offset finding looks very convincing. Before I prepare the fix, could you capture a few exact requests in QModMaster?
Please use Read Holding Registers (FC03) and read these separately:
BT20 (40025): starting address 24, one register; then 25, one register.
BE3 current (40079): starting address 78, two registers; then 79, two registers.
For each request, please send the raw returned 16-bit values, preferably in hexadecimal. A screenshot of QModMaster’s request/response traffic would be ideal—it lets us distinguish the actual wire address from the address displayed in the interface.
Please also include QModMaster’s address-base setting (zero- or one-based) and the pump’s approximate BT20/BT21 temperatures and BE3 current at that time.
Read each request again after a few seconds to allow the gateway cache to refresh. Leave word swap and all other settings unchanged; no writes needed.
This should let us confirm the address translation for both temperatures and 32-bit values without changing the app’s calculations.
The value for grid L3 is difficult to verify against the heat pump’s measurement on the incoming phase, as all phases fluctuate rapidly depending on the house’s demand, solar generation (variable cloud cover right now), and the inverter’s compensation regarding the battery—but both 5.0 A and 3.2 A are reasonable readings for each instance.
Similar values are obtained during a second and third run, with an interval of approximately 5 minutes between them.
I’m not sure if it’s still of interest to start debug logging on the Main device as soon as the heat pump runs a hot water cycle? Regardless, it started just now—on September 16 at 17:19.
Since most values in the app are likely offset in terms of addressing, I am running manual queries via QModMaster, and the values I’ve checked look good.
I’ll get back to you once the hot water cycle has finished and will send a diagnostic report then as well.
Hi! Thanks—these captures confirm an off-by-one error in how the app addresses registers through your connection. The correction is included in test version 1.3.4.
BT20 and BT21 decode correctly, and the BE3 read at address 78 gives 5.0 A with the expected word order. The read starting at address 79 crosses between registers, so it isn’t another BE3 reading of 3.2 A. That misalignment also explains the enormous current values in Homey.
Once you have 1.3.4, please:
Keep writes disabled and confirm Register addressing is 40025 → 24.
Enable Debug logging on Nibe Main before restarting, so we capture startup and reconnection.
Restart the app, then run Repair to repeat feature detection. Note whether Solar is still suggested; an existing unwanted Solar device needs removing manually.
Compare temperatures, phase currents and runtime counters with the pump at roughly the same time. Note any differences.
Leave debug logging enabled through a complete hot-water cycle and note its approximate start and end times.
Afterwards, send both the debug log and diagnostic report, together with your comparisons and cycle times. You can then disable debug logging.
Your exact captures now have regression tests. Energy calculations are unchanged; the corrected addresses should let us properly assess the remaining power and production readings.
I uninstalled 1.3.3 and installed 1.3.4.
After entering 40025->24, it found my heat pump at the correct IP and displayed the correct outdoor temperature!
Then it sampled the features (122).
It once again found 4 devices: Main, Heating, Hot water, and Solar.
Enable debug logging on Nibe Main before restarting
Restart the app
Run Repair (on Main) to repeat feature detection – (feature sampling takes about 2 minutes)
The Solar device was still there – it contained no values and has now been manually removed
I checked the values and they look good, though there are question marks on some of them – I’ll go through them more carefully and send a report – I’ll get back to you…
Sorry, but I forgot to send the diagnostic report…
I’ll give it another go during the next hot water cycle, as the whole process will then be carried out using version 1.3.4.
For anyone on an earlier version than 1.3.3, you need to manually update the app. 1.3.3 has increased the permissions scope to use external homey sensors to help regulate your indoor temperature.
Homey doesn’t auto-update app that has changed permissions scope so you need to do that manually.
Just so you know:
The app suddenly restarted, and all devices disappeared.
After a second, all the devices reappeared—and the “Solar” device came back as well (the one I had manually removed during installation).
I have now manually removed “Solar” again.
I’ve finally had time to go through, test, and trial the app and devices.
As I said, it looks really good, even though there are a few open questions.
See the document here:
Hi! Thanks again for the detailed testing—it has helped identify a concrete correction.
In 1.3.5, I’ve corrected the compressor power units: the reading previously shown as 57 W should be 570 W. This matches the correction used by Home Assistant’s NIBE library. The energy estimate covers compressor and immersion consumption; it doesn’t include every electrical load in the heat pump.
I’ve also fixed the handling of switches/modes and the invalid value behind the false Solar detection.
For production and COP, I’ve expanded the diagnostics to compare eight production counters across a complete cycle. The app now performs two gradual register sweeps and captures energy readings for up to two hours.
Could you please:
Update to 1.3.5 without uninstalling.
Enable debug logging on Main before restarting the app.
Run Repair on Main to repeat feature detection. Keep polling at 10 seconds.
Leave debug enabled for about two hours, ideally starting shortly before a normal hot-water cycle. Include some idle time afterwards. Heating is useful too if it occurs naturally—no need to force heating or immersion.
Note the cycle’s start/end times and any frozen readings, reconnects or unexpected devices. A few timestamped comparisons with the pump display would help.
Send a diagnostic report immediately afterwards, before restarting again, then disable debug. Please send me the report ID and cycle times.
No manual register queries or LOG.SET changes are needed for this round. The aim is to verify the corrected energy allocation and establish which production counters actually advance during the cycle. COP remains unverified for now.
Many thanks for the work you’re putting into this!
Just a quick note for your information: regarding point 3 above, the ‘Repair’ function sampled register 126 (instead of 122, as before).
The timestamps for the operation (which are hopefully included in the debug/diagnostic report) are as follows:
2026-09-22 21.08.29 status: 15005 Heating
2026-09-22 22.23.33 status: 10187 Defrosting
2026-09-22 22.29.33 status: 15005 Heating
2026-09-22 23.06.35 status: 10187 Defrosting
2026-09-22 23.12.36 status: 15000 Starting
2026-09-22 23.13.36 status: 15005 Heating
Unfortunately, there was no hot water cycle during this period.
I’ve spent some time in front of the heat pump comparing the real-time values in the app with the info in the heat pump’s service menu—and it looks really good! You’ve really done a great job putting it all together!
However, I notice the following remaining issues/questions:
Device Nibe Main Immersion heater power – Shows 0 (And that’s likely correct, as it hasn’t been used yet due to the weather/temperature. But I can’t verify this one just yet.)
I am missing these registers under Nibe Main:
40020",“factor”:10,“size”:“s16”,“mode”:“R”,“titel”:“EB100-BT16 Evaporator temp”
40017",“factor”:10,“size”:“s16”,“mode”:“R”,“titel”:“EB100-EP14-BT12 Condenser Out”
Device Nibe Hot Water
Energy delivered – Always shows 0.
Device Nibe Heating
Energy delivered – Always shows 0.
Fan speed – For the ventilation, it always shows 0 – though the fan is actually running at 85.
Thanks for checking the readings against the heat pump—it’s good to hear they’re lining up.
I’ve prepared test version 1.3.6 with:
The missing BT12 and BT16 temperatures.
Improved detection of the documented production counters. Production and COP won’t be recommended when those counters return only zero or no data, but you can still enable them manually.
Better diagnostic retention, so the register-sweep results remain available after the capture finishes.
For fan speed, I’m keeping the actual reading separate from the configured “Normal” speed. If the actual-speed register only returns zero, the app will no longer recommend displaying it.
Once you’ve installed 1.3.6, could you:
Enable debug logging on Main before restarting, then restart the app.
Run Repair on Main, Heating and Hot Water. Check BT12/BT16 and let me know which production source is shown—whole system or EP14—and whether production/COP are recommended.
Shortly before a natural heating or hot-water cycle, toggle debug off and back on to start a fresh capture.
Note the cycle’s start/end times and whether “Energy delivered” increases.
After the cycle, disable debug logging, then immediately send a diagnostic report. Send me its reference and any readings that differ from the pump.
A readable production counter still needs to increase during operation before we can judge whether it gives useful production and COP figures. The energy-allocation calculations are unchanged.
A quick note for your information: regarding point 2 above, the ‘Repair’ function resulted in a sampling of 130 registers (instead of the previous 126).
My heat pump has two climate systems: the main system (EB100-EP14) and a secondary climate system (EP21). The BT12/BT16 values currently displayed are for EB100-EP14. The values have been verified.
Fan speed shows 0%, and there is no indication that the fan speed is set to “Normal.”
Now I am waiting for a normal cycle—either for hot water or heating—to start…
