Having problems adding Heatmiser thermostat to configuration.yaml

andyh747 · March 22, 2025, 11:18am

OK I’ve struggled with this for several hours and cannot get any readings from the stats. I’ve wired the RS485 adaptor to the C & D terminals where the Touchpad is wired and swapped the connections round just in case but no joy.
I think this must be down to the RS485 adaptor but I’ve tried changing various settings with no luck in getting any data. Here’s a screenshot of my RS485 setup page:

This is my configuration.yaml file entry:

climate:
  - platform: heatmiser_ndc
    host: 192.168.1.183
    port: 4196
    scan_interval: 20
    tstats:
      - id: 1
        name: Bedroom Two
      - id: 2
        name: Bedroom Three
      - id: 3
        name: Lounge
      - id: 4
        name: Master Bedroom
      - id: 5
        name: Bedroom Four
      - id: 6
        name: Plant Room

Here’s a link to the adaptor information: Waveshare RS485 to ETH(B)

If anyone can help diagnose why this doesn’t work I’d be really grateful. Thanks for any input.

nigelc · March 26, 2025, 2:26pm

Hi Folks
Ive added a new branch “restructure & simplify” to my repository
See change log and Readme for details

nigelc · March 26, 2025, 2:27pm

Andy
Difficult to tell what’s going on. If you turn on logging, initially at INFO level, that may shed some light on it. If not set logging to Debug (lots more log data then)

Nigel

andyh747 · March 27, 2025, 2:21pm

Thanks Nigel.

I’ve just updated to your latest version but still no data. I’ve added the following to the configuration.yaml file:

climate:
  - platform: heatmiser_ndc
    host: 192.168.1.183
    port: 4196
    scan_interval: 20
    tstats:
      - id: 1
        name: Bedroom Two
      - id: 2
        name: Bedroom Three
      - id: 3
        name: Lounge
      - id: 4
        name: Master Bedroom
      - id: 5
        name: Bedroom Four
      - id: 6
        name: Plant Room
        
logger:
  default: warning
  logs:
    custom_components.heatmiser_ndc.climate: debug
    custom_components.heatmiser_ndc.rs485: info

However I don’t see any info in the logs within HA except this:

This error originated from a custom integration.

Logger: homeassistant
Source: custom_components/heatmiser_ndc/climate.py:112
integration: heatmiser_ndc
First occurred: 2:12:48 PM (17 occurrences)
Last logged: 2:18:08 PM

Error doing job: Task exception was never retrieved (None)
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 1100, in _async_update_entity_states
    await entity.async_update_ha_state(True)
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 978, in async_update_ha_state
    self._async_write_ha_state()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1148, in _async_write_ha_state
    self.__async_calculate_state()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1089, in __async_calculate_state
    if extra_state_attributes := self.extra_state_attributes:
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/heatmiser_ndc/climate.py", line 170, in extra_state_attributes
    "time"               : self._get_day_and_time(),
                           ~~~~~~~~~~~~~~~~~~~~~~^^
  File "/config/custom_components/heatmiser_ndc/climate.py", line 112, in _get_day_and_time
    return f'{_day_of_week[self.dcb[36]-1]} {self.dcb[37]:0>2d}:{self.dcb[38]:0>2d}:{self.dcb[39]:0>2d}'
                           ~~~~~~~~^^^^
IndexError: list index out of range

However I think this may be down to the new clock setting which you mentioned needed more work. If I’m not getting any data from the system then this would explain the error. However should there be a way to see the RS485 data, or lack of, somewhere?
I’m convinced this is down to the ethernet adaptor but I don’t know what should be set on the interface for this to work. I’ve reached out in other places but have drawn a blank so far.

Update:

I changed the protocol setting on the adaptor from None to Modbus TCP to RTU and now get the following error:

This error originated from a custom integration.

Logger: custom_components.heatmiser_ndc.rs485
Source: custom_components/heatmiser_ndc/rs485.py:147
integration: heatmiser_ndc
First occurred: 2:22:08 PM (1 occurrences)
Last logged: 2:22:08 PM

Serial exception: stat= 1 err= read failed: socket disconnected

andyh747 · March 30, 2025, 11:31am

Well looks like I’ll have to give up on this as have tried everything to get this working and am getting nowhere. Keep getting the same error:

This error originated from a custom integration.

Logger: custom_components.heatmiser_ndc.rs485
Source: custom_components/heatmiser_ndc/rs485.py:161
integration: heatmiser_ndc
First occurred: 12:27:06 PM (42 occurrences)
Last logged: 12:31:29 PM

Hard error: too may tries on stat 2
Hard error: too may tries on stat 3
Hard error: too may tries on stat 4
Hard error: too may tries on stat 5
Hard error: too may tries on stat 6

nigelc · March 31, 2025, 4:06pm

Hi Andy

The Hard errors you are now seeing are to be expected if the code cannot read the RS485 interface, or receives no data. I suggest you set the log level for the RS485 module to debug. This should produce copious amounts of debug info in the log file. If you are not seeing anything in the log file, then the log level setting has not been recognised.
I have checked the settings on my interface box (ATC-1000) The UART is set to RS485 mode, 4800 baud, 8 bits, No parity, 1 stop bit, no hardware flow control.
The mode is set to TCP control, server mode, and I use the default port no 23

Good luck
Nigel

nigelc · March 31, 2025, 4:08pm

PS I’m pretty sure you do not want Modbus/RTU protocol

andyh747 · March 31, 2025, 4:30pm

Thanks Nigel, appreciate the reply.

I have my settings set as yours except am using port 4196 rather than 23 - that was the default on the adapter so left it at this.
I’ve had the protocol set to none and MODBUS but no change to the result. However I agree it shouldn’t be on MODBUS.

You mentioned previously that the RS485 connections don’t matter but I’ve reversed them several times with no success.
Many forums suggest that you should have ground connected at each end of the RS485 link. I’m assuming you haven’t this connected?

What I’m slightly confused about is the difference between the Y & B and the C & D connections on the UH1 wiring centres. I have a touchscreen which uses all four connections. The old Netmonitor I had used the C & D connections which is what I’m wiring the adapter into. Just not sure why there are four connections.

I might have to try another RS485 adapter.

calisto99 · April 1, 2025, 7:38am

Hi @andyh747, I can’t really help with debugging but I can explain the RS485 physical connections. The UH1 only has Y & B terminals (at least mine only has Y & B) and in a standard setup these terminals would be connected to the Y & B terminals of the TouchPad (also each thermostat has Y & B connections from the UH1). If a NetMonitor is added to the system, this is connected to the C & D terminals of the TouchPad - hopefully this is what your system looked like beforehand. The RS485 protocol only allows for one Master in the system and everything else (in this case all the thermostats) are slaves. Both the TouchPad and the NetMonitor are Master controllers but only one of these is allowed to be Master at any one time - otherwise there’s a clash and the whole protocol breaks down. So the system is designed with the TouchPad as the Master by default (as it connects directly to the Y & B terminals of all the stats). When the NetMonitor wants to talk to the stats, it does so via the C & D terminals; in this way the TouchPad can detect the NetMonitor wanting to communicate with the system (via the C & D terminals) and it will “step-aside” momentarily and let the NetMonitor become the Master. So use of the Y/B and C/D terminals allows arbitration so that there is only ever one Master in the system at any one time. I hope that makes sense.

calisto99 · April 1, 2025, 7:39am

So in your setup, the old NetMonitor should be physically disconnected from the C & D terminals of the TouchPad and the RS485 lines of your new adapter board connected to the C & D terminals instead. From your posts, I think this how you have it all wired? To clarify the RS485 polarity, my working setup has the A+ connected to the C terminal and the B- connected to the D terminal.

calisto99 · April 1, 2025, 7:47am

@andyh747 Your adapter board configuration looks fine. In my case, the configuration was correct, but it was the mis-configuration of additional functionality on the adapter board that was the problem - but it looks like you’ve tried everything. Is it possible that the failure of your NetMonitor could be down to some sort of failure of the C & D terminals at the TouchPad? You could temporarily disconnect the TouchPad and wire the adapter board directly to the Y & B terminals of the UH1 and see if that works. I’m lucky in that I own an oscilloscope and could probe the RS485 lines to see if data was being sent/received or not - and in this way I could confirm that it was the adapter board not doing its job properly. But there’s also a couple of LEDs on my adapter board that flash as the data is being sent and received (I don’t know if your adapter board has similar lights?)

If you disconnect the adapter board RS485 lines and just run the HA program, do you get exactly the same errors?

andyh747 · April 1, 2025, 8:39am

Thanks for the replies Mark, really appreciated as I’ve been pulling my hair out (what’s left of it ).

Your explanation of the architecture makes perfect sense and I now understand why there’s Y&B as well as C&D.

You’re absolutely correct in how I’ve setup the system and how it’s connected. What I will now check is which way round I have the C&D terminals connected to the RS485 + & - connections although I have swapped these round several times.

The Netmonitor died as a result of a failure on the board - I think due to a faulty PSU. I disconnected the Netmonitor and simply wired the adaptor to where the Netmonitor was connected (C&D). I have three UH1s in the property all linked via the Y&B terminals. The Touchpad is wired to the second UH1 via terminals C&D and works fine. The Netmonitor was wired to the third UH1 via C&D. However to eliminate an issue on the terminals for the Netmonitor I did disconnect the Touchpad from the UH1 and connected the adaptor direct but same result - although I did use C&D for this not Y&B so maybe worth a shot this way. However if the Touchpad is working correctly then it would suggest the RS485 connections on C&D are fine and this is down to the adaptor.

I’ve been in contact with Waveshare support and although not very helpful they confirmed for raw RS485 connections to make sure the protocol is set to none which it is. Other than that it’s either down to some obscure setting on the adaptor interface or it’s faulty.

I’ll experiment a bit more today and see if I can get anything out of the adaptor. To answer your question on LEDs, yes the adaptor has three, one for power, one for a successful TCP link and one for data. The data one is flashing so some sort of data is flowing but it’s not getting to HA.

I’ll also disconnect the Touchpad and try using Y&B terminals for the adaptor.

Thanks again for your valuable input, it does help to ensure I haven’t done something stupid.

calisto99 · April 1, 2025, 9:13am

And if you disconnect the adapter board RS485 lines and just run the HA program, do you get exactly the same errors?
It is looking more and more to be a problem in the adapter - once you’ve exhausted everything else that has to be the next thing to try. The adapter that I bought only cost £18 on eBay and I know that works - for a system setup as large as yours, I think it would be worth a punt. I feel your pain as I went through a similar process

andyh747 · April 1, 2025, 9:25am

I just went to test a few scenarios and noticed the Touchscreen had lost data from the system. I had to reboot everything in a power cycle and now the Touchscreen is back and working fine.

However HA now reporting the following. This is with the adaptor connected.

This error originated from a custom integration.

Logger: homeassistant
Source: custom_components/heatmiser_ndc/climate.py:112
integration: Heatmiser_ndc
First occurred: 10:23:08 AM (1 occurrences)
Last logged: 10:23:08 AM

Error doing job: Task exception was never retrieved (None)
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 1100, in _async_update_entity_states
    await entity.async_update_ha_state(True)
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 978, in async_update_ha_state
    self._async_write_ha_state()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1148, in _async_write_ha_state
    self.__async_calculate_state()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1089, in __async_calculate_state
    if extra_state_attributes := self.extra_state_attributes:
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/heatmiser_ndc/climate.py", line 170, in extra_state_attributes
    "time"               : self._get_day_and_time(),
                           ~~~~~~~~~~~~~~~~~~~~~~^^
  File "/config/custom_components/heatmiser_ndc/climate.py", line 112, in _get_day_and_time
    return f'{_day_of_week[self.dcb[36]-1]} {self.dcb[37]:0>2d}:{self.dcb[38]:0>2d}:{self.dcb[39]:0>2d}'
                           ~~~~~~~~^^^^
IndexError: list index out of range

andyh747 · April 1, 2025, 2:13pm

So have spent considerable time on this today with zero success.

I disconnected the adaptor and got no errors. I only get the above error with the adaptor connected. Also if the adaptor is disconnected I get the thermostats showing unavailable but when connected they show no data - see attached. So it appears some sort of communication is happening but it’s not being read correctly.

Adaptor not connected:

Adaptor Connected:

I can also confirm that HA is talking to the adaptor as with HA shutdown the link LED shows no connection and as soon as HA starts the LED goes blue indicating a successful link.

andyh747 · April 12, 2025, 12:49pm

So after trying everything possible and getting nowhere I ordered another RS485 to IP converter.

Just connected it and exact same issue. No data being displayed and same errors as previous adaptor.

There’s obviously a problem somewhere in my setup but the Touchpad is working perfectly so no idea what’s causing the issue.

Update 1:

Sorry for the updates but the saga continues with a twist.

After trying two different RS485 adaptors and getting nowhere I looked again at my screenshots above pointing out that when the RS485 adaptor was disconnected the thermostats showed unavailable but when connected showed no data. I decided to just try raising the temperature in one zone above the set target and it correctly signalled the UH1 and switched the zone on. Confirmed operation by reducing temperature and zone switched off.

So it appears this is a one way comms problem. The system is receiving commands from HA but it’s not getting any data back from the system and hence all temps showing zero.

@nigelc any thoughts on the above and any reason why TX is working bit not RX? I’ve tripled checked connections and all are correct. When I send the signal from HA it reports an error - see screenshot below. What is causing this list index out of range error???

Update 2:

Not sure if this will help anyone else but after trying multiple methods to fix this I turned to ChatGPT - yes I know shoot me! However it did find the problem.

After examining the logs in more detail it turns out the integration was reading the first thermostat correctly and reporting the correct data but the integration then crashed. After examining the climate.py file it seemed there was an issue with the time/date entry which @nigelc had added in the latest update. It was down to something in the “extra_state_attributes(self) → dict:” which was crashing the integration for me. Initially I just commented out this entire bit and the data from the thermostats all showed correctly. After that ChatGPT rewrote the file correctling whatever was wrong and it all now shows correctly in HA.

I have no idea what exactly was the issue and why it worked for others and not me - perhaps others are using the older version . For interest here was the explanation from ChatGPT:

Thanks for sharing your full climate.py file — that helps a lot.

Why you were getting errors

The problem was not in extra_state_attributes itself but likely in the way Home Assistant tried to access it during initialization, especially if the dcb list wasn’t valid yet (e.g., read from the thermostat failed on startup). This means self.dcb could be an unexpected type or contain bad data early on, which caused attributes like self.dcb[36] to raise an exception.

You’ve already commented out the extra_state_attributes section before, which avoided the crash — proving the issue was there. The good news is: your code is well-structured, and the fix is just a small update.