Heatpump going into Alarm mode

[Manhem]

I have got a problem at home where my Home Assistant stopped working. So now it's disconnected from the network. I left the ESP8266 connected to my heatpump. The morning after my heatpump has got into Alarm mode. I reset the pump and left it for a day, but when I came back from work it has gone into Alarm mode again. I don't know what happends and I can't go into the log file, Home Assistant is disconnected.

I have a Nibe F1145 and to that I have connected a ESP8266 with the latest firmware.

[elupus]

Home assistant running or not, should not affect the gateway function. Is the alarm modbus40 alarm?

[Tommatheussen]

I have been having the same issue for a couple of days as well. For me, I get notified via NIbeUplink about the alarm, see the screenshot about the info:

just resetting the alarm makes it work again for a while, it seems sort of random, I haven't been able to find out if the ESP goes offline or not

EDIT: It does seem like my heatpump just continues working fine with the alarm, even if I don't clear it

[elupus]

@Tommatheussen dont remember, where you on esp32 or esp8266?

[Tommatheussen]

According to the LilyGo datasheet, it should be ESP32.. I see @Manhem is using ESP8266, so this might actually be a different issue.

Any ideas on how to capture some usefull info when the alarm happens?

[elupus]

You could turn on debug logs and keep a esphome log window open on as separate computer.

Do you guys have stable wifi networks where your esp is located? I have heard reports that if wifi is down, the GW doesnt start properly.

[elupus]

Could also be worth updating to 2.1.0 release if you have not.

[Tommatheussen]

My wifi network should be pretty stable, I'm not having any issues with other devices (also not other ESPHome devices). That being said, I have to admit the location (and orientation) of the heatpump is not ideal for wifi access, I just noticed in my unifi dashboard that it can't even connect to the AP which I expected (the signal has to pass through 1 tick wall AND the heatpump itself).

[Manhem]

No problem with WiFi at my place. The alarm is for Modbus, what I can see.

I have the latest firmware, I test that for you on a ESP8266.

[user1048576]

A theory:

If HomeAssistant goes down, the ARP entry for that address will eventually be removed from the ESP32 (or 8266) device.

That will prevent the packet from being sent on the network. Now, I don't know if ESPHome is based on FreeRTOS, and I don't know how FreeRTOS behaves when trying to send UDP packets to a destination for which the MAC address is not known, but I would guess this it is some of kind of exceptional flow that might be handled by a timeout or in worst case the UDP transmission function call hanging until the MAC address is known?

I looked in the code, NibeGw.cpp, and it seems the reception of RS485 packets, the ack/nack of those and the transmission UDP packets are done in the same context, so if the transminssion of UDP packets hang, or has a very long timeout, there will be no acks sent to the heatpump.

Again, I'm not very familiar with ESP32 or ESPHome, this is just a theory which I have not verified. I hope nobody is offended by me having a theory about something I'm not familiar with, just saw this issue when planning to setup a NibeGw for HomeAssistant.

[elupus]

Absolutely not offended. I hope its not a hanging/blocking state to be missing am arp entry. But im not fully sure on that. Would be worth investigating if you have the time.

[user1048576]

I can try to further investigate it once I get that far.

Setting up HomeAssistant and NibeGw is just a fun project for me now during christmas/newyear holiday, so it does not have high prio.

[user1048576]

It seems my theory was incorrect. I've setup an emulated environment, an RS485 device sending packets simulating a heatpump, and then taking HA up and down, and the nibegw device keeps sending acks no matter the state of the HA, and no matter the arp entry is there or not (I can see with tshark that the nibegw after a while start sending arp request instead of real UDP packets to HA, one or a few minutes after I take HA down)

I have some more ideas I will try to investigate.

[Tommatheussen]

I still can't say for sure what the actual issue seems to be, but I can tell you that adding the following to my esphome config helped massively:

wifi:
  power_save_mode: none

The reason why this isn't the full solution, it that, since I added this part, I've had the alarm trigger twice. If I have some time, I'll disable it and try to get debug logging from the ESPHome, in the meantime, I think it's safe to assume there's something that going wrong when the wifi connection is not stable (enough)...

[user1048576]

I've had my ESP32 running flawlessly now for a few weeks.

Based on what you write @Tommatheussen, and also from reading the code, I think what happens is that the function:

udpread.writeTo(data, len, (uint32_t)std::get<0>(target), std::get<1>(target))

hangs in some exceptional flow down in the network stack causing the executing thread to hang,

I have not been able to replicate this problem, my installation works flawlessly so far. In any case I think it would be beneficial to have the reception/ack of RS485 packets in another thread/task than the sending of UDP packets to HA.

If there is a problem with UDP/WiFi communication in that case, it would not affect the thread doing the RS485 communication. That is not the way it is now, now it is done in the same thread.

I'm personally not very good at C++ programming, I only do C and assembly, but I don't think it is too much work for someone familiar with C++.

[jonaswikstrom]

I am a new user of esphome-nibe and I also have this problem. I have had my system up running 48 hours now and my Nibe F750 have gone into alarm mode twice.

Quite a beginner concerning esphome, modbus and Nibe. The system still works even after if the warning goes on, just needs to reset though.

My WiFi is really good, and _power_savemode is set to none.

[elupus]

I am a new user of esphome-nibe and I also have this problem. I have had my system up running 48 hours now and my Nibe F750 have gone into alarm mode twice.

Quite a beginner concerning esphome, modbus and Nibe. The system still works even after if the warning goes on, just needs to reset though.

My WiFi is really good, and _power_savemode is set to none.

What hardware are you running?

[jonaswikstrom]

Using an ESP32 DevKit together with a MAX485 RS485 Tranciever.

[jonaswikstrom]

Discussed the problem with Fredrik Anerdin, contributor on the NibePi project. He commented "Nibepi regularly checks and resets this alarm. Shouldn't be that hard to put in the ESP code to check a register and restore it."

Is there a way to reach a specific register through the gateway and do this?

[jonaswikstrom]

The register for restore all red alarms should be by sending a 1 to 47171. Cant reach this from Home Assistant though.

[elupus]

There is a reset alarm button in home assistant. You can create an automation based on the alarm number.

[remcoongit]

Hi, I'm having the same problem as described above here. Randomly goes into 251 modbus error state. I have a F2120-20, SMO40, RMU40 I've first tried an ESP8266 with MAX485 while that caused the error to occur every day at least once. I've then bought a lilygo-t-can485 as in the examples here. This brought the amount of errors down to once every few days.

I'm not a very experienced c++ developer either but it seems @user1048576 made a suggestion to split the network task from the modbus task.

Rather than trying the work around to automatically reset (I've configured the SMO40 to keep going on modbus errors) and in homeassistant configured an auto button press once the error 251 occurs, is there someone that would be willing to help trying the idea of @user1048576 ?

Adding screenshot of homeassistant log;

thanks!

[Lenael]

Hi @remcoongit ! I experienced the same issues with modbus error on similar configuration: F2120-12 and SMO40. I have the same errors in the HA logs. I also tried Lilygo and ESP8266, now I'm testing ESP32-ETH on which I'm using ethernet cable rather than Wifi to eliminate radio errors. Unfortunately, SMO40 still reports modbus errors from time to time (once a day). I plan to investigate the C++ code when I have some free time. Did you manage to fix that in any way? How did you configure SMO40 to run despite of 251 alarm?

[elupus]

The alarm doesn't stop the pump normally. But you can add an automation to trigger the reset button if the alarm code is 251

[remcoongit]

Hi @remcoongit ! I experienced the same issues with modbus error on similar configuration: F2120-12 and SMO40. I have the same errors in the HA logs. I also tried Lilygo and ESP8266, now I'm testing ESP32-ETH on which I'm using ethernet cable rather than Wifi to eliminate radio errors. Unfortunately, SMO40 still reports modbus errors from time to time (once a day). I plan to investigate the C++ code when I have some free time. Did you manage to fix that in any way? How did you configure SMO40 to run despite of 251 alarm?

Hi, In the SMO40 settings (If I recall correctly, in the MODBUS menu - otherwise if you can't find it I'll search for it again) you can configure the heatpump to continue on error. This obviously is a bad practice but without setting this flag, I have at least once a day that the MODBUS error pops up, it indeed stops operating.
@elupus what you say is not correct from my experience.

As you can read from my reply already... I did not figure out how to fix it. It's a shame the ESP32-ETH did not work either and indicates there are some other issues with the code. I've created an automation in homeassistant that automatically resets the 251 alarm which works OK but not optimal. During winter this happens not only once a day but a few times a day.

`- id: "nibe-251-error-reset" description: "" mode: single trigger:

• platform: state entity_id:
  • sensor.alarm_45001 to: "251" for: hours: 0 minutes: 1 seconds: 30 condition: [] action:
• service: button.press data: {} target: entity_id: button.smo40_alarm_reset `

[elupus]

Have you guys run the esp with debug enabled?and checked its log for error?

In general this stuff tends to happen due to the esp being to slow/busy with other things causing it to miss a byte from the pump.

Network is usually the cause. But could be something else. Not sure what esphome version you guys are running. Ive not upgraded mine in quite a while so something can have changed.

[Lenael]

@remcoongit Thanks! I found some general setting making a pump work normally when any error occurs. I also use similar automation but it's not ideal solution.

@elupus I haven't tried yet to turn on debugging - will do it. I also bought an ESP32-S3 which should be faster than the one I'm currently using. Gonna test that as soon as it arrives.

[Lenael]

@elupus I made some progress thanks to your comment about ESP performance! To speed things up I removed all of the "ESP_LOGD(...)" entries (responsible for writing debug informations to esphome console) from nibegw component code, I then installed it on the ESP32 and almost all the 251 errors are gone - I got only single error per few days when the heatpump finishes heating the water. Seems like this is the correct path to follow. I'm going to test it again with ESP32-S3 as soon as they arrive here. Thanks again for your help!

[remcoongit]

That's fantastic. Could you let me know how I can use the changes you made? Really curious about the ESP32-S3 as well!

[Lenael]

I can create a fork of nibegw repository but I may do it in a week (I'm on holiday).

You can also do it yourself:

1. clone nibegw repository https://github.com/elupus/esphome-nibe.git or download sources as a .zip
2. edit NibeGwComponent.cpp and remove (or comment out) all calls to ESP_LOGW( ... )
3. edit you esphome configuration and replace this:

external_components:
  - source: github://elupus/esphome-nibe

with this:

  external_components:
  - source:
      type: local
      path: <path_to_your_edited_nibegw_source_files>

This should do the trick :-)

[elupus]

If log level is not DEBUG LOGD calls should not really matter much.

[elupus]

Might help to use HighFrequencyLoopRequester in esphome. Im not sure exactly how and when to enable it though.

[Jo69-S]

After replacing the AccessPoint, I was able to analyse the error situation in the WLAN and the error 251. The WLAN connection is always disconnected after exactly 15 minutes (to the second). The Lilygo immediately tries to re-establish the connection. If this takes too long, the error message comes from the NIBE. For me, it was enough to switch off the 5GHz network and have a 2.4GHz network with good reception. Even MAC filtering on the 5GHz network took too long again.

[mattisalo]

I struggling to to get nibegw to work. pump goes to 251 error state. What i have done so far:

1. i tested with nibepi and with that all is ok and pump does not go to error state.
2. i tested rasppberri nibegw in same hardware that nibepi and nibegw app works for wew seconds and hangs. there is some serial init tweak that fixes this, but still pump goes to error state.
3. now i'm testing esp8266 and esp32 with rs485 adapter with ESPHome. i see data coming from pump, but it goes to error state.

clip of the data:

15:16:46][D][nibegw:030]: UDP Packet with 6 bytes to send
[15:16:46][D][nibegw:030]: UDP Packet with 6 bytes to send
[15:16:46][D][nibegw:030]: UDP Packet with 6 bytes to send
[15:16:46][D][nibegw:030]: UDP Packet with 31 bytes to send
[15:16:47][D][nibegw:030]: UDP Packet with 6 bytes to send
[15:16:48][D][nibegw:030]: UDP Packet with 6 bytes to send
[15:16:48][D][nibegw:030]: UDP Packet with 6 bytes to send
[15:16:48][D][nibegw:030]: UDP Packet with 6 bytes to send
[15:16:48][D][nibegw:030]: UDP Packet with 6 bytes to send
[15:16:48][D][nibegw:030]: UDP Packet with 6 bytes to send
[15:16:48][D][nibegw:030]: UDP Packet with 6 bytes to send
[15:16:48][D][nibegw:030]: UDP Packet with 6 bytes to send
[15:16:48][D][nibegw:098]: Constant to address: 0x20 token: 0xee bytes: 7
[15:16:49][D][nibegw:030]: UDP Packet with 6 bytes to send
[15:16:49][D][nibegw:098]: Constant to address: 0x20 token: 0xee bytes: 7
[15:16:49][D][nibegw:030]: UDP Packet with 6 bytes to send
[15:16:49][D][nibegw:098]: Constant to address: 0x20 token: 0xee bytes: 7
[15:16:49][D][nibegw:030]: UDP Packet with 6 bytes to send
[15:16:49][D][nibegw:098]: Constant to address: 0x20 token: 0xee bytes: 7
[15:16:49][D][nibegw:030]: UDP Packet with 6 bytes to send
[15:16:49][D][nibegw:098]: Constant to address: 0x20 token: 0xee bytes: 7
[15:16:49][D][nibegw:030]: UDP Packet with 6 bytes to send
[15:16:49][D][nibegw:098]: Constant to address: 0x20 token: 0xee bytes: 7
[15:16:49][D][nibegw:030]: UDP Packet with 31 bytes to send
[15:16:51][D][nibegw:030]: UDP Packet with 6 bytes to send
[15:16:52][D][nibegw:030]: UDP Packet with 6 bytes to send
[15:16:52][D][nibegw:030]: UDP Packet with 6 bytes to send
[15:16:52][D][nibegw:030]: UDP Packet with 6 bytes to send
[15:16:52][D][nibegw:030]: UDP Packet with 6 bytes to send`

Config:

esphome:
  name: nibe-esp32
  friendly_name: nibe-esp32
  platform: ESP32
  board: esp32dev
  #framework:
  #  type: arduino

# Enable logging
logger:
  baud_rate: 0
# Enable Home Assistant API
api:
  encryption:
    key: "6BvxPU+hQZf0S1g9X2L57Nm9yhlefVPcToHx4YCgVvU="

ota:
  password: "b3260ba01ad74542d0ad779f4b7d3d63"

wifi:
  power_save_mode: none
  ssid: "*****"
  password: "*******"
  fast_connect: true # Fast connect to connect to my hidden network

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

captive_portal:

#external_components:
#  - source: 
#      type: git
#      url: https://github.com/elupus/esphome-nibe.git
#    components: [ nibegw ]

external_components:
  - source: github://elupus/esphome-nibe    

uart:
  rx_pin: GPIO16
  tx_pin: GPIO17
  baud_rate: 9600

nibegw:
  udp:
    target:
      - ip: 192.168.11.170
        port: 9999

    source:
      - 192.168.11.170

  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

Anu ideas how to debug more why nibepi is working but not nibegw?

[elupus]

Depending on the rs485 tranceiver you may need to configure the tx enablement pin.

[mattisalo]

i have this: https://www.ebay.com/itm/165836464829 and i use same combination ( esp8266 + rs485) with my vallox airconditioning with success. this module does not have dir pin. Should it work without?

[elupus]

No does not look like it. Does the transmit led indicator light up from time to time?

[mattisalo]

In the end it really was the direction pin. There wasn't connector for direction, so i de soldered few legs from the pcb and did my own direction wire. Now it works fine. Thanks for the help!!!

[elupus]

In the end it really was the direction pin. There wasn't connector for direction, so i de soldered few legs from the pcb and did my own direction wire. Now it works fine. Thanks for the help!!!

Weird design on that PCB then. Cant see how transmit would ever work :)

[mattisalo]

There was a "automatic direction control" when data in pin had traffic it had kind on loop back connection to direction pin with help of 7404 chip. seems that the same connection works with vallox AC because it mosly reads and does not have to answer in to line, but not with nibe because of the reply.

[FransTwisk]

I installed a LilyGo T-CAN485 with ESPHome Nibe in my Metro Therm SBH10-06 (which is a Nibe rebrand and interface is same as the SMO40) last weekend, and had my first 251 alarm within a couple of hours. Since then it happened 1 to 5 times a day.

In my Unifi logs I noticed the LilyGo would actually reconnect to WiFi every 15 minutes (just like what @Jo69-S described) and even though WiFi strength is not great in the area it is installed, it should be good enough for a contant connection.

In the ESPHome docs I found that there is a default timeout of 15 minutes to wait before rebooting when no client connects to the API. Setting this to 0 (disabled) has solved the 15 minutes reboots for me, and thus far no alarm has been triggered. Not sure if there are any downsides though (or why this is needed in the first place). I guess maybe the Nibe Heat Pump Integration doesn't actually use this API?

# Enable Home Assistant API
api:
  reboot_timeout: 0s
  encryption:
    key: "..."

[elupus]

Interesting. Api is not really needed to have enabled.

[remcoongit]

Also going to try that!

[remcoongit]

It's finally cooling down in the Netherlands and the heatpump is running again. Unfortunately the 'reboot_timeout' made no difference. I'm getting the 251 error around 3 times a day now. (fri,sat,sun)

[elupus]

It's finally cooling down in the Netherlands and the heatpump is running again. Unfortunately the 'reboot_timeout' made no difference. I'm getting the 251 error around 3 times a day now. (fri,sat,sun)

Are you still getting errors in HA logs? Have you looked at the logs from the ESP with debug enabled?

[remcoongit]

I did not this time but here's something I could find in Homeassistant, consistent with the drop of the temperature outside, 14th October.

I did not get any errors in the past months (hot water is also going via heatpump so its daily active)

---

Logger: nibe.nibe.connection.nibegw Source: /usr/local/lib/python3.11/site-packages/nibe/connection/nibegw.py:220 First occurred: October 14, 2023 at 10:11:44 AM (191 occurrences) Last logged: 7:58:41 AM

Bad logger message: Unexpected exception during parsing packet data '5c5c016d024c0135' from ('IPADDRESS', 9999) ((StreamError('Error in path (???) -> data -> version\nstream read less than specified amount, expected 2, found 1'),)) Bad logger message: Unexpected exception during parsing packet data '5c5c016a024c0135' from ('IPADDRESS', 9999) ((StreamError('Error in path (???) -> data -> value\nstream read less than specified amount, expected 4, found 0'),)) Bad logger message: Unexpected exception during parsing packet data '5c5c0162018902' from ('IPADDRESS', 9999) ((StreamError('Error in path (???) -> data -> flags\nstream read less than specified amount, expected 2, found 0'),)) Bad logger message: Unexpected exception during parsing packet data '5c5c0162018802' from ('IPADDRESS', 9999) ((StreamError('Error in path (???) -> data -> flags\nstream read less than specified amount, expected 2, found 0'),)) Bad logger message: Unexpected exception during parsing packet data '5c5c0162018702' from ('IPADDRESS', 9999) ((StreamError('Error in path (???) -> data -> flags\nstream read less than specified amount, expected 2, found 0'),)) Traceback (most recent call last): File "/usr/local/lib/python3.11/site-packages/nibe/connection/nibegw.py", line 182, in datagram_received msg = Response.parse(data) ^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/construct/core.py", line 288, in parse return self.parse_stream(io.BytesIO(data), **contextkw) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/construct/core.py", line 300, in parse_stream return self._parsereport(stream, context, "(parsing)") ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/construct/core.py", line 312, in _parsereport obj = self._parse(stream, context, path) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/construct/core.py", line 787, in _parse return self.parsefunc(stream, context) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "", line 58, in parseall File "", line 32, in parse_struct_1 File "/usr/local/lib/python3.11/site-packages/construct/core.py", line 4598, in _parse obj = self.subcon._parsereport(stream, context, path) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/construct/core.py", line 312, in _parsereport obj = self._parse(stream, context, path) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/construct/core.py", line 2120, in _parse subobj = sc._parsereport(stream, context, path) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/construct/core.py", line 312, in _parsereport obj = self._parse(stream, context, path) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/construct/core.py", line 2653, in _parse return self.subcon._parsereport(stream, context, path) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/construct/core.py", line 312, in _parsereport obj = self._parse(stream, context, path) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/construct/core.py", line 4837, in _parse return self.subcon._parsereport(io.BytesIO(data), context, path) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/construct/core.py", line 312, in _parsereport obj = self._parse(stream, context, path) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/nibe/connection/nibegw.py", line 477, in _parse obj = self.subcon._parsereport(stream2, context, path) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/construct/core.py", line 312, in _parsereport obj = self._parse(stream, context, path) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/construct/core.py", line 3919, in _parse return sc._parsereport(stream, context, path) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/construct/core.py", line 312, in _parsereport obj = self._parse(stream, context, path) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/construct/core.py", line 2120, in _parse subobj = sc._parsereport(stream, context, path) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/construct/core.py", line 312, in _parsereport obj = self._parse(stream, context, path) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/construct/core.py", line 2653, in _parse return self.subcon._parsereport(stream, context, path) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/construct/core.py", line 312, in _parsereport obj = self._parse(stream, context, path) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/construct/core.py", line 4295, in _parse obj = self.subcon._parsereport(stream, context, path) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/construct/core.py", line 312, in _parsereport obj = self._parse(stream, context, path) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/construct/core.py", line 5101, in _parse data = stream_read(stream, self.decodeamount, path) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/construct/core.py", line 91, in stream_read raise StreamError("stream read less than specified amount, expected %d, found %d" % (length, len(data)), path=path) construct.core.StreamError: Error in path (???) -> data -> flags stream read less than specified amount, expected 2, found 0

[Leeo0n]

I do have the same problem with my SMO40, RMU40 and f2120-16. I have tried all the different options with both the examples. All without success. @remcoongit did you find anything that can help in te last few weeks? @Lenael is your suggestion still working correctly without any errors?

[elupus]

If you have an rmu40, make sure your esp config does not ACK the rmu message too.

[remcoongit]

Unfortunately no, it's cold again so it happens between 3-7 times a day now.

@elupus how to configure that?

Current config:

esphome:
  name: "nibegw"
  comment: Nibe SMO4
  platform: ESP32
  board: esp32dev

wifi:
  power_save_mode: none
  fast_connect: true
  networks:
  - ssid: "nibewifi"
    password: "12345678-not-going-to-share-12345678"

captive_portal:
api:
  reboot_timeout: 0s
ota:
logger:

external_components:
  - source: 
      type: git
      url: https://github.com/elupus/esphome-nibe.git
    components: [ nibegw ]

# 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.
      target:
        - ip: 10.x.x.1
      source:
        - 10.x.x.1

    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

[elupus]

Looks like your config is correct. Do you have long lines to your rmu40? Your could try disconnecting it and disabling the accessory in the pump to rule out issues with that.

[remcoongit]

Yes the distance to the RMU40 is about 15 meters. I'll try disconnecting tonight and see if any new errors popup. If the RMU40 is connected without the nibegw esp it runs fine and no issues.. What if this would still be the problem? What would be the solution?