[APP][Pro] Nibe Live -- Local Nibe control, split into the devices you actually automate

Well, now it’s working as expected. I just had to wait a little longer.

Energy used for periodic charging (hot water) is linked to Nibe Main rather than Nibe Hot Water. Is that by design?

When trying to modify these values I get an error:

Edit: Nevermind, now I can change settings. I disabled “Only read from Modbus” in S735 settings.

No, it shouldn’t. The power and energy assignment follows the priority of the main device. So as long as that says hot water (which I think it should), it would get assigned to hot water. Not 100% sure on heat pump behavior here though.

After upgrading and restarting my mesh network, Nibe Live has no connections. I’m pretty sure the ip for my S735 has not changed, and neither trying to repair connections nor restarting Live app help.

Do I need to delete and install Live devices again, and probably loose all data history?

Hm, that’s odd.
Have you tried running a repair on the devices?

In either case, please send me a diag.

Actually, the ip had changed and after saving the correct address all Nibe parts are live again.

I have also now reserved the new address in my network. :slightly_smiling_face:

Hi @hyper!
I’m back after successfully getting my F730 to output data via Modbus TCP.
I didn’t buy the MODBUS 40, as I don’t think it’s worth the money.
Instead, I got a LilyGo T-CAN485 and installed a slightly modified version of GitHub - nptr/nibegw-esp: firmware for a custom modbus gateway for NIBE heatpumps · GitHub.
Using the Nibe ModbusManager, I generated a LOG.SET file containing 15 parameters for the F730.
After quite a bit of trial and error, the F730 is now sending these 15 parameters via Modbus to the LilyGo T-CAN485, which in turn outputs them to a local static IP on port 502.

I installed your app, added a device (S-series), and entered the IP manually. It indicated that it found values ​​(main). However, none of the data in the device is correct, so I assume a specific F-series device profile is required…?
With that said, I’d be very interested in trying to get your excellent app working with my F730. I’m not sure what you might need from me, though?

Please, take your time – I’m in no rush.
Thnx!

Interesting! Yeah, I would need to add a mapping for F-series too. Would this mean your device follows the the same register set or is the T-CAN device remapping anything?

The T-CAN485 uses the same registers as Nibe, as they originate from the LOG.SET file.
The LOG.SET file is defined and generated using the Nibe ModbusManager software and then installed on the F730 via a USB drive.
The T-CAN485 only reads the registers transmitted by the F730 (as specified in LOG.SET).
If you attempt to read registers not included in LOG.SET, it returns error code 04 (Slave device failure).
I don’t know if this helps, but nibegw-esp/resources/models at master · nptr/nibegw-esp · GitHub lists potential registers (in JSON format) for a number of Nibe models.
However, for the T-CAN485 (nibegw-esp), the crucial factor is which registers are actually defined in the LOG.SET file.
More information about LOG.SET and ModbusManager can be found in the PDF at this link: https://professional.nibe.eu/document/Installatörshandbok/031725-10.pdf?\_gl=1\*1z0leu\*\_up\*MQ..*_ga*OTQ2Njc5MTYxLjE3ODkxMjIyMzE.*_ga_VKQ42SERH5*czE3ODkxMjIyMzEkbzEkZzEkdDE3ODkxMjIzMzkkajYwJGwwJGgw
See pages 13–15.

Beautiful, thanks!

I’ve got another release in review which needs approval first, but should be able to push a test version next week.

A quick addition:
You can query any register in the heat pump using the T-CAN485/nibegw-esp; HOWEVER, it takes at least 2 seconds to receive a response from the heat pump, and you can only query one register at a time—no block reads.
So, it is not limited to the registers listed in LOG.SET.
Practical approach: You can include your 20 (or fewer) most important or frequently requested registers in LOG.SET for rapid reading, and then supplement this with occasional, slower on-demand reads (one at a time, with >2 seconds latency—ideally at a lower polling frequency) for the rest.
This is also exactly how Nibe’s own MODBUS 40 accessory operates.

Great feedback, will incorporate.

Hi @Krisstenswe ,

A few things would help me prepare the first beta:

  1. Could you share your LOG.SET file, or an export/list of its parameters?

  2. Could you share your modified nibegw-esp source or describe the changes? Are Modbus writes enabled?

  3. Which firmware version is your F730 running?

  4. Is BT50 installed, and is room regulation enabled, or do you control heating through the heating curve?

  5. If convenient, could you check whether these registers are readable: 43086, 43375, 43141, 43084, 42437 and 42439? They cover operating priority, compressor/immersion power and produced energy. A few values while the compressor is running would be particularly useful.

No need to change pump settings or test writes yet—the files and configuration details alone would help a lot.

Thanks!

Hi @hyper!

  1. Here is the link to LOG.SET: Microsoft OneDrive
    Here is the link to the JSON file retrieved via Nibe’s MyUplink API from my F730: Microsoft OneDrive

  2. The changes I made are minor, and nothing has been done to affect the basic functionality. The changes were made solely to ensure compatibility with the LilyGo board.
    It is easy to enable write access to the heat pump. However, I have deliberately chosen not to activate write operations for the time being. The reason for this is that writing to certain registers—while technically writable—affects the heat pump’s EEPROM. Since EEPROM has a limited number of write cycles over its lifespan, I do not want to “accidentally” write frequently to a register until I am certain it does not impact the EEPROM. For example, I previously wrote to a register once an hour to adjust the heating curve; that write operation goes directly to the EEPROM and, in other words, affects the heat pump’s lifespan. I have stopped that write operation…

  3. 9721R3. This should be the latest version for my heat pump.

  4. While I do have access to 40032 Room temperature (EP21-BT50), control is handled via the heating curve.

  5. 43086 is available and currently returns ‘10’.
    43375 is available and currently returns ‘0’.
    43141 is available and currently returns ‘0’.
    43084 is available and currently returns ‘0’.
    42437 is available and currently returns ‘0’.
    42439 is available and currently returns ‘0’.
    However, what surprises me is that none of these registers—except for 43084—are included in the attached JSON file. Could this be a “flaw” in the API, where these registers simply aren’t being transmitted from the boiler to the cloud?
    (I currently have no demand for heating or hot water, so the compressor isn’t running at the moment.)

  6. I’ve noticed a discrepancy in the register table included in nibegw-esp (the one I linked to earlier, F730.json): that file lists 43136 as “Compressor Frequency, Actual,” whereas the JSON response from the API lists 41778 as “Current compressor frequency.” 43136 shows a value of 0, while 41778 shows a value of 4. I can’t think of a way to verify which one is correct right now—I’ll simply have to wait until I hear the compressor running and then check the respective registers.

Thanks, this helps a lot!

I checked the files. Your LOG.SET contains 12 parameters, including 43084. The other five energy parameters aren’t included, but as you explained, they should still be accessible through individual reads.

Before the beta, the most useful check would be during an ordinary compressor run:

  • Read 43086, 43375, 43141 and 43084 while it’s running.

  • Read 42437 and 42439 before and after a complete heating or hot-water cycle.

  • Include approximate times and whether it was producing heating or hot water. If possible, include the raw values before scaling.

Zero compressor power while idle makes sense. The production counters are cumulative, though, so I wouldn’t expect those to become zero just because the compressor stopped. We need to establish whether they’re populated on your pump.

The cloud export also uses different IDs for some values—for example, it exposes priority as 49994, whereas the Modbus reference uses 43086. So the frequency discrepancy alone doesn’t mean the Modbus table is wrong.

One clarification: 40032 / EP21-BT50 belongs to climate system 2. Do you have a second heating circuit installed?

And absolutely fine to leave writes disabled. We can do the first tests entirely through readings; there’s no need to enable controls or force a compressor run.

Thnx!

I’ll have to get back to you with tests regarding the registers you asked about. I’ve set up a test environment that logs when the heat pump starts up either hot water production or space heating.

I have a second heating system; the first supplies the radiators upstairs, while heating system no. 2 supplies the underfloor heating on the ground floor. However, as I mentioned, the indoor temperature doesn’t actually control anything at the moment—it’s just a sensor.

On a completely different note—something that might be useful to know: I’ve run some other tests and can definitively conclude that it’s impossible to retrieve registers from 50000 upwards via Modbus on an F-series pump. It does work via the MyUplink API, though.
Requests for registers above 49999 generate an “Illegal Data Address” error.
To try and work around this, I manually added register 50095 to the LOG.SET file. The heat pump accepted the modified LOG.SET file, but I still get the “Illegal Data Address” error. It seems to be due to a deeper software restriction within the heat pump itself—the F-series operating system appears to be programmed to handle only registers up to 50000 via the physical RS485 interface. Even though the log configuration is “valid,” the unit’s internal Modbus system refuses to output that specific data onto the cable. In other words, Nibe seems to have chosen to lock registers from 50000 upwards exclusively to their own cloud service (myUplink) for the F-series models—or at least for my F730.

Now I have finally got a run on the heat pump for hot water!

See logging at: https://1drv.ms/x/c/74d267ae29fb24ed/IQBN_V418C62QoXSPNLu4SrDAXrv3c3TKUVq-mLoXa-sW_E?e=rPGva0

Great, thanks.

I’ve uploaded a 1.3.2. test version, give it a go.

The first F-series test version is prepared: 1.3.2, with the driver labelled Nibe F-series (beta).

Once installed, please:

  1. Add the F-series driver using nibegw-esp and your gateway’s connection details. Detection may take several minutes. Send screenshots of the functions it finds.

  2. Leave polling at 10 seconds and gateway writes disabled. Compare the main temperatures with the pump display. Your curve-controlled heating should have no room-thermostat dial.

  3. Enable Debug logging on Main shortly before an ordinary hot-water cycle. Note when it starts/stops and whether Homey’s active function and power readings follow.

  4. Send a Homey diagnostic report promptly afterwards, with those approximate times.

  5. If practical, restart the app once and check that everything reconnects.

Could you also confirm whether the numbers in your CSV were raw register values or already scaled? The beta’s watts/kWh are still provisional, and COP cannot be validated while the production counters remain zero.

For faster energy readings, please add 43086, 43375, 43141, 42437 and 42439 through ModbusManager if possible, retaining your existing parameters. Let me know which LOG.SET configuration you use.

No need to test controls or force heating/immersion. Pairing and one normal hot-water cycle are enough for the first round.

Exciting!

I’ll start the installation later today when I have a bit more uninterrupted time.

The values ​​in the CSV were raw values, without scaling.

Here is the new LOG.SET file, which is now installed in the heat pump:

Note: The rule stating a maximum of 20 registers in LOG.SET turned out to be not entirely accurate. Registers with a bit length of u8 or u16 count as a single register, whereas u32 registers take up two “slots.” To fit the ones I wanted alongside the ones you requested (43086, 43375, 43141, 42437, and 42439), I had to rearrange the file.

OK, I’ve installed version 1.3.3 now.
I set up an F-series device.
When I selected nibegw-esp, it didn’t detect the unit automatically.
I entered the IP address manually, and it started the “Detecting features” process (122 registers).
It finished after a few minutes.
It added 4 devices. (Solar?)
In the document below, I have listed the values ​​shown for each device and compared them with the readings from Nibe’s MyUlink app.

I will provide the debug log and diagnostic report as soon as a hot water cycle has been completed.