Step-by-step configuration

[Gigatrappeur]

Hello,

I'm sorry, this not a real issue but is it possible to add a step-by-step for use lilygo TTGO T-CAN485 ESP32 CAN RS-485 ? I'm experimented developer but I'm not confortable with esp or arduino...

I saw the photo for the electrical connections, this very helpful. But I need a procedure for how to plug in the card, compile the code and download it to the card? Many thanks in advance

I'd really like to use this board rather than the official Nibe modbus module which costs ~700€

Best regards

[bgarderhagen]

Hi.

Here are some steps from how i remember it quickly:

• Add ESPHome integration in Home Assistant
• Go to the ESPHome dashboard added on left side
• Click new device
• "Open ESPHome"
• Connect your LillyGo by USB cable to the computer running the browser
• Connect and deploy to new device
• Edit the YAML file. Look at the example file on git
• Install YAML file to ESP

This will deploy nibegw to the LillyGo.

Then add the Nibe integration and connect it to the ip of the nibegw.

Hope this helps you along.

Can make a video or something later if required

//btg

[Gigatrappeur]

Ok, I'll buy the card and if I have any difficulties, I'll ask and we can add steps in the tuto ;-)

Thanks a lot

[waelzindani]

This is amazing. Just got my card and I will install it in the weekend. If there is any video pls paste the link. Have a nice evening!

[vesar-github]

Hi!

I just received my LilyGo T-CAN485 board today. As a fresh Home Assistant user and absolute first timer for ESP32, I found this step by step. I will record here what I did and how far I got in a bit more detail for others to follow. Maybe someone can help me onward or comment about best practices for the next one to install their setup. I will update this with any corrections you may point out.

As said, I am a total newbie. My procedure may be totally wrong.

Thanks to @bgarderhagen for the step by step to start with. @Gigatrappeur, @waelzindani, did your installation go ok?

My setup: Home assistant running on Raspberry Pi 4b with HAOS + another desktop PC as UI. No ESPHome anything installed in the house beforehand.

1. In UI PC, in Home assistant, go to Settings -> Add-ons and search for ESPHome

2. Click ESPHome

3. Click Install

4. After Installation, Click START and then OPEN WEB UI

5. In WEB UI, click + NEW DEVICE

6. UI computer warns about not browsing the dashboard with a HTTPS-connection, but that You can connect the device to the computer running ESPHome dashboard. That will be the Raspberry with HAOS. No worries if You have access to that computer. So continue.

7. Give a name to the configuration and credentials to your Wifi, where the LILYGO will reside.

8. Configuration is created. Press INSTALL.

9. Connect the LILYGO board to the computer running ESPHome dashboard with USB. In this case, the Home Assistant server.

10. Select "Plug into the computer running ESPHome dashboard"

11. The device is found, select device.

12. Installation starts and takes a couple of minutes. You can see log running as installation proceeds.

13. After successful installation, you can see your LILYGO device in your network

14. You should assign a static IP for your LILYGO in your network router.

15. In Home Assistant go to Settings -> Add-ons -> ESPHome -> OPEN WEB UI, and you should see the device you just created being ONLINE

16. Go to settings -> Devices and services. You should now see ESPHome as newly found. Add that. You can see one device with no information.

17. In Home Assistant go to Settings -> Add-ons -> ESPHome -> OPEN WEB UI

18. Click SECRETS

19. Add a row for OTA_PASSWORD and set your own password

20. Change default generated names WIFI_SSID and WIFI_PASSWORD to lowercase wifi_ssid and wifi_password to comply with the nibegw code example - or modify the code example later to use lowercase, if you already use the names elsewhere

21b. Just a newbie question, are these case sensitive? Was this item necessary at all?

22. In your new device, click EDIT to edit the code. In my case, the default code is as follows:

esphome:
  name: nibe-f1255
  friendly_name: Nibe_F1255

esp32:
  board: esp32dev
  framework:
    type: arduino

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "XXX"

ota:
  password: "XXX"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Nibe-F1255 Fallback Hotspot"
    password: "XXX"

captive_portal:

23. Replace all the code above with the code found in https://github.com/elupus/esphome-nibe/blob/master/examples/lilygo-t-can485.yaml

24. In code, replace your Home Assistant IP address in the target

    target:

    • ip: 192.168.255.254 -> Change to your HomeAssistant IP

25. Your code should now be as follows:

esphome:
  name: nibe-f1255
  comment: Nibe-f1255 heat pump
  platform: ESP32
  board: esp32dev

# General ESPHome setup
api:
  reboot_timeout: 0s

ota:
  password: !secret ota_password

logger:

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  fast_connect: true # Fast connect to connect to my hidden network
  # It is recommended to disable powersave mode on wifi, to make sure the device does not miss UDP requests sent.
  power_save_mode: none
  # The device needs a static IP. Either do that here with the manual_ip node, or do it via another way (router)

# Load nibe component
external_components:
  - source: github://elupus/esphome-nibe

# Set pins required for LilyGo T-CAN485 board
output:
  - platform: gpio
    id: ENABLE_PIN # Enable the chip
    pin:
      number: GPIO19
      inverted: true
  - platform: gpio
    id: SE_PIN # Enable autodirection
    pin:
      number: GPIO17
      inverted: true
  - platform: gpio
    id: ENABLE_5V_PIN # Enable 5V pin for RS485 chip
    pin:
      number: GPIO16
      inverted: true

# Configure uart that will be used
uart:
  rx_pin: GPIO21
  tx_pin: GPIO22
  baud_rate: 9600

# Configure NibeGW
nibegw:
  udp:
    # The target address(s) to send data to. May be a multicast address.
    # When using Home Assistant: this is your Home Assistant IP.
    target:
      - ip: 192.168.XXX.XXX (Your own Home assistant IP here)
        port: 9999 #The Nibe Home Assistant integration listens to 9999 by default 

    # List of source address to accept data from, may be empty for no filter
    source:
#      - 192.168.255.254 Had to comment this row away, the integration would not install before. And now that I think of it, in the example code this was the same as the Home assistant IP. What does this actually do?

    # Optional port this device will listen to to receive read requests. Defaults to 9999
    # read_port: 9999

    # Optional port this device will listen to to receive write request. Defaults to 10000
    # write_port: 10000

  acknowledge:
    - MODBUS40

  # Constant replies to certain requests cabe made
  constants:
    - address: MODBUS40
      token: ACCESSORY
      data: [
            0x0A, # MODBUS version low
            0x00, # MODBUS version high
            0x01, # MODBUS address?
      ]

# Some helper functions to restart ESPHome from HA
button:
- platform: restart
  name: Nibegw Restart
- platform: safe_mode
  name: Nibegw Safe Mode Boot 

26. Click SAVE

27. Click INSTALL and follow the procedure as before in items 10...

28. Disconnect your LILYGO from Home Assistant computer and supply it power via USB. Check that it becomes online wirelessly and that you can see it ONLINE in Home Assistant by going to Settings -> Add-ons -> ESPHome -> OPEN WEB UI

After an amount of fiddling, I got the following to show in my Home Assistant

So I can only see 1 device and 3 entities.

29. Power off your Nibe heat pump and Connect the LILYGO to your pump as described in Nibe MODBUS 40 manual. The image in examples, worked fine for me. Note that LILYGO has very bad markings for the power connector. GND is the one closest to the edge of the circuit board.

30. Power up your Heat pump and enable MODBUS in the heat pump menu

31. Check the ESPHome that the device becomes ONLINE.

32. Go to Settings -> Devices and services and click + ADD INTEGRATION

33. Serch for Nibe and click Nibe heat pump

34. Click NibeGW

35. Select your heat pump Model and fill in your NibeGW IP address, other values should stay default.

36. Click SUBMIT

37. After a short while, the NibeGW is found and you can allocate it to desired area. The integration becomes available.

OK, I can now see my heat pump in home assistant.

Next, setup to get the values I want shown.

To be continued... maybe a bit later

Vesa

[waelzindani]

Hello This is great. I started and finished the first part which is ESP but the weather has been bloody cold here and I havent had the time to finish. You are a much better newbie than I am haha.

[Gigatrappeur]

Hello guys,
Yes, I've successfully installed lyligo card. Some initial difficulties with connecting the card to ESPHome, but in the end it seems to work.

However, some values are missing, such as the outside temperature. I have a probe connected to the nibe and the nibe displays this temperature on its screen. But I don't know how to retrieve it in HA.

[elupus]

Enable the sensor

[vesar-github]

So I did select some items with ModbusManager and updated the LOG.SET file to the heat pump as instructed in the Nibe MODBUS 40 manual. As a point of focus, I selected phase currents of my main switchboard; I have current transformers there connected to the heat pump to save the main fuses.

This in where info I found in web gets a bit vague and I definitely would like to document this in an easier format. Did I get it right, that the max. 20 items that are defined in LOG.SET, will be "pushed" regularly (how regularly?) by the heat pump, and other values need to be pulled?

How does the Home Assistant integration work, then? There are 982 entities in my integration. I can not make a difference between the ones I have configured in LOG.SET and others. Any one of them can be enabled. If I enable one that is in the LOG.SET, the value updates automatically, and if a parameter is not in the LOG.SET, the integration will query for it?

Here you can see my history of phase currents. Not very impressive, lots of unavailable values. Quite a low update interval. How would I go and debug this? Pinging the LILYGO gives steady response with less than 10 ms delay. The heat pump has not gone to error state.

Attached also a bit of my log. Only irregularity I can spot is intermittent group of lines with [18:01:45][D][nibegw:085]: Response to address: 0x20 token: 0x69 bytes: 6 logs_nibe-f1255_logs.txt

I'll fill in my step by step once I get this sorted out.

[elupus]

Whatever you do, dont enable all sensors. That will cause really low update rate. The more you enable the slower it gets. Some senors can also break the update causing unavailable data.

Start with only the ones in your logset. Then enable more as you need them.

[vesar-github]

I had 7 sensors enabled, 3 of them were somehow enabled by "default" or automatically when I installed the integration. Now I dropped it to three, only the phase currents left. Still a lot of unavailability, no visible change in how the history graph is drawn.

Makes me wonder, did my heat pump accept the LOG.SET. Is there an easy way to verify this? Then again, even if not, i guess it should be able to regularly update three values.

[elupus]

Check log for errors.

Ps..no i dont think there is an easy check for log set.

[tobbensoft]

Maybe a stupid question, but where do I find ModbusManager, using esphome-nibe with success but a better update speed on some values would be great :)

[vesar-github]

Nibe MODBUS 40 manual says "ModbusManager can be downloaded via www.nibe.se/kommunikation". That takes you to a page, where you can find menu PROFFSHJÄLP (Professional help) -> KOMMUNIKATION -> NIBE Modbus. Direct link here.

I had trouble finding similar in Nibe Finnish home pages.

[vesar-github]

Nothing fishy in ESPHome DEBUG logs as far as I understand.

Setting logging to VERY_VERBOSE was too much for the ESP to handle, the heat pump went to alarm state. Nevertheless, I collected some amount of log logs_nibe-f1255_logs_VV_.txt. I just can't say, is there something I should worry about, and is that just because verbose logging overloaded the ESP.

There are several times entries like:

[21:52:14][W][component:214]: Component nibegw took a long time for an operation (0.05 s).
[21:52:14][W][component:215]: Components should block for at most 20-30ms.

but i didn't see these when logging was VERBODE or DEBUG. Is that because these are very verbose only, or did this only happen when overloading the ESP?

The part, which I understand more of, seems to be ok. Shielded cable of 30 cm length between the Nibe and LILYGO should not produce errors to communication.

Then I set Nibe integration to debug logging, and this kind on rows were present:

2024-01-23 22:31:56.392 DEBUG (MainThread) [homeassistant.components.nibe_heatpump] Some coils failed to update, and may be unsupported: Failed to read some or all coils (Failed decoding response for eb100-be1-current-40083: Failed to decode eb100-be1-current-40083 coil from raw: 6a00, exception: Invalid raw data size: given 2, expected at least 4)

A bit longer sample:

2024-01-23 22:29:41.646 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring coil 40080 - coil definition not found
2024-01-23 22:29:43.633 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring coil 40083 value 6c00 - failed to decode
2024-01-23 22:29:43.633 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring coil 40084 - coil definition not found
2024-01-23 22:29:43.634 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring coil 40081 value 3c00 - failed to decode
2024-01-23 22:29:43.634 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring coil 40082 - coil definition not found
2024-01-23 22:29:43.635 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring coil 40079 value 4700 - failed to decode
2024-01-23 22:29:43.635 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring coil 40080 - coil definition not found
2024-01-23 22:29:46.628 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring coil 40083 value 6c00 - failed to decode
2024-01-23 22:29:46.628 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring coil 40084 - coil definition not found
2024-01-23 22:29:46.629 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring coil 40081 value 3b00 - failed to decode
2024-01-23 22:29:46.629 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring coil 40082 - coil definition not found
2024-01-23 22:29:46.630 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring coil 40079 value 4500 - failed to decode
2024-01-23 22:29:46.630 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring coil 40080 - coil definition not found
2024-01-23 22:29:47.032 DEBUG (MainThread) [homeassistant.components.nibe_heatpump] Skipping seeded coil: 40079
2024-01-23 22:29:48.661 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring coil 40083 value 6c00 - failed to decode
2024-01-23 22:29:48.661 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring coil 40084 - coil definition not found
2024-01-23 22:29:48.662 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring coil 40081 value 3b00 - failed to decode
2024-01-23 22:29:48.662 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring coil 40082 - coil definition not found
2024-01-23 22:29:48.662 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring coil 40079 value 4500 - failed to decode
2024-01-23 22:29:48.663 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring coil 40080 - coil definition not found
2024-01-23 22:29:50.433 DEBUG (MainThread) [homeassistant.components.nibe_heatpump] Some coils failed to update, and may be unsupported: Failed to read some or all coils (Failed decoding response for eb100-be1-current-40083: Failed to decode eb100-be1-current-40083 coil from raw: 6c00, exception: Invalid raw data size: given 2, expected at least 4)
2024-01-23 22:29:50.434 DEBUG (MainThread) [homeassistant.components.nibe_heatpump] Finished fetching Nibe Heat Pump data in 3.402 seconds (success: True)
2024-01-23 22:29:50.666 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring coil 40083 value 6900 - failed to decode
2024-01-23 22:29:50.667 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring coil 40084 - coil definition not found
2024-01-23 22:29:50.667 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring coil 40081 value 3f00 - failed to decode

[elupus]

Interesting. Seems we are getting a lot of data we dont underatand. Could you remove the log.set file again? Looks almost like it might be sending data in a weird format.

[vesar-github]

I actually did make another LOG.SET with only those three currents to try, did not help.

Now I left logging not activated and even selected "Ignore LOG.SET" in the heat pump, what ever that did. It's difficult to say with the heat pump UI, because you lose the menu once you remove the USB stick. Was that what you mean by removing the LOG.SET? At least the data did not get any better, still unavailable a lot.

Looking at Nibe Debug log a bit wider, some checksum rows also stand out from "background noise". Quite a few of those, and then the checksum errors just suddenly stop appearing.

2024-01-23 21:42:50.453 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring packet from ('192.168.1.235', 9999) due to checksum error: 5c00206900df
2024-01-23 21:42:51.286 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring packet from ('192.168.1.235', 9999) due to checksum error: 5c00e6d02064c45c00025502087d205c00027e92155c0002900092065c00206b004b5c00206b
...
2024-01-23 21:47:39.859 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring packet from ('192.168.1.235', 9999) due to checksum error: 5c0020685085a84c006fa94f0080a8c7006d9f0000a3a93c00fda735fccc6721939c6a00949c0000919c4000929c00008f9c4500909c0000ffff0000ffff0000ffff0000ffff0000ffff0000ffff0000ffff0000ef5c
...
2024-01-23 21:48:14.914 DEBUG (MainThread) [homeassistant.components.nibe_heatpump] Skipping seeded coil: 40083
2024-01-23 21:48:16.635 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring packet from ('192.168.1.235', 9999) due to checksum error: 5c0020685085a84c006fa94f0080a8c8006d9f0000a3a93c00fda735fc449c0b00939c6c00949c0000919c7d48c606008f9c4600909c0000ffff0000ffff0000ffff0000ffff0000ffff0000ffff0000ffff0000985c
2024-01-23 21:48:17.780 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring packet from ('192.168.1.235', 9999) due to checksum error: 5c0020685085a84c006fa94f0080a8c8006d9f0000a3a93c00fda735fc449c0b00939c6c98190600919c3d00929c00008f9c4600909c0000ffff0000ffff0000ffff0000ffff0000ffff0000ffff0000ffff0000985c
2024-01-23 21:48:22.484 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring packet from ('192.168.1.235', 9999) due to checksum error: 5c0020685085a84c006fa94f0080a8c8006d9f0000a3a93c00fda735fc7fb600939c6c00949c0000919c3d00929c00008f9c4700909c0000ffff0000ffff0000ffff0000ffff0000ffff0000ffff0000ffff0000995c
...
2024-01-23 21:48:43.516 WARNING (MainThread) [nibe.nibe.connection.nibegw] Ignoring packet from ('192.168.1.235', 9999) due to checksum error: 5c0002a0321016fc5c00025502087d205c0002900092065c0002a0020064c45c00025502087d205c0002900092065c0002a0020064c45c00

Latest log attached. Thank you already for the support, hope to find out something that might help others in the future too. home-assistant_nibe_heatpump_2024-01-23T21-28-48.910Z.log

I'll be traveling for work for a couple of days, will get back to this when I'm back home again.

[elupus]

The checksum issues can occur of the esp is overloaded. If you still have it set to verbose logging, turn that down.

The other warnings looks to be due to "EB100-BE3 Current" values enabled in LOG.SET. They are 32bit and seem to have been split over two parameters.

I don't think you managed to disable the LOG.SET in your last log.

[tobbensoft]

I tried using LOG.SET and got similar results to you @vesar-github

I think I managed to disable it by putting an empty LOG.SET file on the usb and doing the process again

[vesar-github]

Logging was already dropped to VERBOSE, now at DEBUG (little difference between VERBOSE and DEBUG).

OK, I also made an empty LOG.SET file. Seems to be disabled now, although it did nothing to history graph.

In addition to the 32 bit currents, I added some temperatures too that are 16 bit values. And yes, they seem to graph fine! Very low update interval, but one problem at a time. So is it something in my setup that messes up the 32 bit values, or is there something in the way nibegw handles 32 bit values?

[elupus]

32bit values in log set is known to be buggy.

32bit values can be broken if your wordswap setting is wrong.

[tobbensoft]

I have graphed 32-bit degree minutes for some time now, that works fine.. Is it only some 32-bit values?

Is that the problem we get with LOG.SET values or is that a different thing?

[vesar-github]

Confirmed. I also added 32 bit degree minutes, and that draws a nice, continuous graph. Phase current values are often unavailable.

LOG.SET is now empty.

[vesar-github]

@elupus, any ideas on where this issue (some 32 bit values being constantly ok and some constantly not) might originate? Heat pump, NibeGW, configuration, something else? In other words, is there anything one can do?

Another thing is the update frequency. @tobbensoft, how often do you get updates? My values update about once per minute, no matter if there is one or twenty enabled entities. Any ideas how to chenck, whether the heat pump is slow to answer or Home Assistant is slow to ask? My assumption is that a much faster update frequency should be possible. My assumption may me wrong :)

[tobbensoft]

@vesar-github I have a lot of entities enabled, so my update frequency is maybe 2mins. But i would say I have no problems with the values as such, just a little slow compared to other technologies.

It would be nice to be able to prioritize the one important in the LOG.SET and the other ones just comes as we roll through the enabled entities.

Just added the EMK 500 flowmeter to my VVM 500 / F2120-20 so I can measure produced heat in kWh :)

[elupus]

32bit values from log.set are broken. Otherwsie they should work as long as your wordswap setting is correct on the pump.

[vesar-github]

@tobbensoft Yeah... My specific interest are just the phase current values (which are now broken) and with high update frequency (which is not the case now) :( This way I would avoid installing a second set of current transformers to my already crammed main electric panel for load balancing.

Well, still investigating. And considering a Shelly pro 3EM...

[vesar-github]

Thanks a lot @elupus, finally got this confirmed. I made a log.set with just "phase 2 current" in it. And yes, the two other phases made a nice graph, only phase 2 got unavailable values. Is this something wrong with Nibe heat pump, as in would the official modbus accessory produce the same result anyway or it this something that has not been reverse engineered yet?

Experimenting with a couple of 16 bit temperature values, both om them in log.set had about 1...2 second update frequency, while removing one of them lowered its update frequency to about one minute. As a matter of fact, no matter if I have 1 or 20 entities enabled, the update frequency outside log.set seems to be about one minute. By your experience, is such a low refresh rate normal behavior? Reading MODBUS 40 manual, I would expect something faster. @tobbensoft, could you please repeat this test with only one value enabled in HA? Same results?

Manual readout is time consuming and only
one value at a time can be read, max timeout
2,1 s. The parameter does not have to be in-
cluded in the LOG.SET file. 

Manual

[elupus]

Its wrong in our parsing of logset 32bit values.

Refresh rate is by default 1minute. We dont want to overload the pump. There is at the moment no way to tune individual entities refresh rate. You can ask any entity to refresh with an automation (update entity service), but thay will cause a full refresh of all entities.

[vesar-github]

OK, thanks again. I don't want to log too many values - in fact, I can fit all other interesting parameters in the log.set. There should be plenty of room to up the refresh rate with automation.

Any time you might decide to develop this further, I'll be available to help with field testing :)

[tobbensoft]

@vesar-github I got similar results to you, LOG.SET works if you avoid 32-bit values and updates are nice and speedy.

Around 1 minute for everything else.