Betriebsart Raum maybe broken

[AndyNew2]

The value for "IDM_Wärmepumpe: Status Verdichter 1" seems still not right. It should be according spec "Aus = 0" or "Ein = 1". It shows "Nicht Verfügbar" for me. Does this mean the value is not transferred at all. I need to observe how the value changes when the heatpump is running.

I attach the log with the new release. That is great! Thanks again for your work.. The Debug and log is brilliant, saves me work and easy to create logs now...

By the way I checked again my room sensors. The Roommode is wrong for me for all rooms. Probably it is the other way around. The good ones, without an exception are even more corrupted than the ones with crazy values. I activated now my heatpump and I still see the value "Off Aus" for nearly all rooms except the ones with the crazy values. And the values seems changing when I change the room mode. However I was not able to detect anything. My room sensor cabling is out of spec because our great installation team did a lot of failures... I fixed the missing termination restistor on the Zonemodule, however I didn't notice much change...

Log is here, all included. All rooms should report room mode automatic. I changed Zonemodul 1 room 3 to "Normal" and room 4 on the same Zonemodule to "Eco". home-assistant_idm_heatpump_2023-10-24T20-02-09.783Z.log

[kodebach]

The value for "IDM_Wärmepumpe: Status Verdichter 1" seems still not right.

According to the logs the integration received the raw value 0, which should be interpreted as "off" and displayed as "Not running" (or "Läuft nicht", if your Home Assistant is set to German).

The fix required changing the ID of the sensor to avoid confusion around the value (see release notes). Could it be that you are looking at the old sensor instance?

The Roommode is wrong for me for all rooms.

Apart from the broken values, the raw value received via Modbus is always 0 for the room modes. I'm sorry but I can't really help you here. As far as the integration is concerned, everything works as expected.

You should probably contact IDM (technical) support and tell them that you cannot correctly read the "Betriebsart Raum" (that's what the IDM documentation calls it) registers via ModbusTCP. They don't really need to know any details about this integration, since the raw value read via ModbusTCP is already wrong, so no setup using ModbusTCP would work correctly.

If you need something to test without this integration, you can try https://github.com/SciFiDryer/ModbusMechanic. For example the settings for "Zonenmodul 1 Betriebsart Raum 1" would be:

Clicking "Transmit packet" shows the current raw value under "Response value".

[AndyNew2]

Sure understood. Yes you are right, I missed to rename the old values. Now it work perfectly. Of course you can't fix my corrupted values. I hoped there is a relationship but this seems not to be the case. I can life with that, and I don't really need the room mode.

Perfect issue can be closed.

[AndyNew2]

And yes I am in contact with my support. iDM never answers and always refers to local service providers. I had soo many issues, I am happy it runs at all. They will for sure not guarantee me correct values in the TCPmodbus implementation.

[kodebach]

If it is a hardware issue and IDM doesn't have technicians in your area, you may be out of luck. But the heat pumps definitely have a remote access feature for IDMs service team (I think you need to grant access somewhere first) so they should at least be able to check for software/configuration issues.

If your heating is working as expected and you see the correct values in the IDM interface, I doubt it's an installation issue.

To get further with support, you could ask them whether 2007 is the correct Modbus register for "Zonenmodul 1 Betriebsart Raum 1". Ask them to confirm that with the firmware engineering team. Since we already found one error (https://github.com/kodebach/hacs-idm-heatpump/issues/34#issuecomment-1766942148) it's not impossible that the issue is simply incorrect/out-of-date documentation.

I'll keep the issue open in case you hear back from them. If you find out that it was an issue with your hardware, just close the issue.

[AndyNew2]

Fine. I have more issues. The Output from Zonemodul do not match sometimes the values shown in the iDM GUI as well. I am in contact with my supplier, however my impression is, they can't really do something. Really a bad situation. In my case the cabling had been done incorrectly as they did not use the specified wires. To exchange that now, would mean to replace 100m kabel inside the house, nearly impossible... However don't worry I keep pushing and will report. In case the values are correct after a final fix, we can savely close the issue, if we have new findings we still can correct...

[kodebach]

Don't know when your heat pump was installed, but it seems more and more like case for the EU's 2-year legal guarantee ("Gewährleistung"). Your system is clearly not functioning as intended/advertised and it doesn't look like it's your fault. AFAIK for the first 12 months the manufacturer/installer would also have to prove that the issue is your fault and not theirs. Doesn't make it any less annoying to swap 100m of cables, but at least it's a way of getting them to do the work properly. (obligatory IANAL)

[daemonenstall]

As requested in my feature request, here is my log. Software version of the Navigator is 20.22-198-gbb5209994

Once I had also trouble with one of my zone modules. One temperature/humidity sensor was showing ridiculous high values and the whole zone module was periodically connecting and then disconnecting. Luckily I had a spare sensor and access to the installation menu (I did the whole cable stuff for the pump on my own and the sensor wires are different from the iDM suggestion). I replaced the sensor, but the problem with the zone module was still persistent. Since I was still in warranty, I called my local service provider and they replaced the zone module. They told me that my case was the second or third failing zone module they have ever experienced. They take care for hundreds of pumps.
home-assistant_idm_heatpump_2023-10-26T08-47-19.976Z.log

[kodebach]

Looking at the logs @daemonenstall's zone modules also only report 0 or garbage values for all rooms. So this probably isn't a hardware issue after all. Seems like either the there is a bug in the firmware or the Modbus documentation from IDM is wrong (or both).

Software version of the Navigator is 20.22-198-gbb5209994

I've got 20.23-19-gdb55e4e94, but I don't have zone modules so I can't say if that makes a difference.

[AndyNew2]

My heatpump installation is just 6 month ago. Yes warranty is still on, however I should have hold money back. I trusted them they did a reasonable installation after the temperature values appears in the heatpump. However comparing to damonstall it is unclear, how it should behave. My heatpump version is 20.22-252-g46df5882c. It is an iPump A3-11 as well. I am in contact with the supplier to find a fix. My biggerst issue in the moment is the Zonemoduls didn't control the valve-controller (Ventilantrieb) in a correct way. Mainly I observe random controllers not disabling and keeping the value unnessary open. That corrupts the control, since it still heats rooms even thinking the room is no longer in the loop. @daemonenstall It would be a help, if you could observe your controls as well. The valve-controller are typically very slow, but there is a LED for each relay on the zonemodul you see from outside. Can you please check and report if this LEDs are always in line with the screen shown on the heatpump or app from IDM. This is not the case for me...

[daemonenstall]

I will have a look at the leds/app tomorrow. Up to now we are very satisfied with the pump and the service provider. We got a JAZ of nearly 4 and we enjoy the cooling mode during the summer.

[daemonenstall]

Sorry for the late reply. There was a wallbox and a flu to battle.

@AndyNew2 I have also noticed, that the reported states of the valves are not in line with the Navigator Control. The valve for Bad OG was clearly open and the led on the zone module was on when I made this screenshot.

Today I had a closer look and I have compared the values read by the HASS Integration, ModbusMechanic and my old NodeRed flow. The latter two variants report the correct values from the Navigator control. The registers are correct, for sure. My NodeRed approach was running for about 3 years and I have never experienced such a strange behavior. I also don't think that we are dealing with a hardware/wiring issue. Why should other values (temperature, humidity, etc.) being transferred correctly and just the Betriebsart is going nuts?

The Integration reports strange values for a couple of rooms. Log is attached. home-assistant_idm_heatpump_2023-11-07T17-47-39.665Z.log

[kodebach]

Today I had a closer look and I have compared the values read by the HASS Integration, ModbusMechanic and my old NodeRed flow. The latter two variants report the correct values from the Navigator control. The registers are correct, for sure.

In your NodeRed flow, did you read the registers one by one?

Maybe the IDM firmware doesn't like the fact that the integration reads a whole block of registers and then splits up the data, e.g. read from register 2000 with length 36 and split all that up into the values for Zone 1 Rooms 1-5. Not sure why this would only be an issue for the room modes, but I'll see if read the registers one by one fixes it.

[kodebach]

Please try the new v0.5.0-beta03 and report back whether things have improved

[daemonenstall]

Yes, the registers are read one by one with Nodered, just like with ModbusMechanic. I have just tried the new beta and the problem is still persistent.

BTW: Writing the solar excess register works fine. 👍

[daemonenstall]

What I have noticed is, that it are always the same rooms that are affected.
Zonenmodul 1 (5 rooms): 3 and 5 Zonenmodul 2 (6 rooms): 3, 5 and 6

[kodebach]

Could you please post debug logs again just to verify that the change in the new beta worked and it is indeed loading the registers one by one.

[daemonenstall]

home-assistant_idm_heatpump_2023-11-08T10-29-08.226Z.log

[kodebach]

Ok seems the new version in fact does not change anything. Registers are still loaded only as a group. I'll have to try again...

[kodebach]

v0.5.0-beta04 is released and this time I could verify it actually loads a single register if loading as a group didn't work. Please try again, and report back.

[daemonenstall]

The crazy values are still present, but the integration shows "off" instead of "unknown". All of my rooms are set to "automatic" (=1), but the integration reports "off" (=0) for all rooms. Of course I have checked this with NodeRed and ModbusMechanic. home-assistant_idm_heatpump_2023-11-08T13-03-49.584Z.log

[kodebach]

Ah okay, once again I didn't implement the change correctly... I had verified that it loads a single register, if the decoding from the group produces an error. However, I accidentally also made it so that decoding unknown room modes results in the default "off" instead of an error. So the new logic didn't trigger for room modes...

Sorry for the confusion. Please try one more time with v0.5.0-beta05.

[daemonenstall]

Still no change. 2023-11-08 15:24:15.567 DEBUG (MainThread) [custom_components.idm_heatpump] raw value (uint16) for zone_1_room_3_mode: 32453

home-assistant_idm_heatpump_2023-11-08T14-25-23.736Z.log

[kodebach]

Are you sure? Did you check the values displayed in Home Assistant?

In the logs I see:

2023-11-08 15:24:15.567 DEBUG (MainThread) [custom_components.idm_heatpump] raw value (uint16) for zone_1_room_3_mode: 32453
2023-11-08 15:24:15.567 DEBUG (MainThread) [custom_components.idm_heatpump] decode failed for zone_1_room_3_mode, retrying with single fetch
Traceback (most recent call last):
  File "/config/custom_components/idm_heatpump/sensor_addresses.py", line 274, in decode
    return (True, self.enum(value))
                  ^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/enum.py", line 712, in __call__
    return cls.__new__(cls, value)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/enum.py", line 1135, in __new__
    raise ve_exc
ValueError: 32453 is not a valid RoomMode

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/config/custom_components/idm_heatpump/idm_heatpump.py", line 144, in _fetch_sensors
    available, value = sensor.decode(decoder)
                       ^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/idm_heatpump/sensor_addresses.py", line 276, in decode
    raise ValueError(f"decode failed for {value}") from error
ValueError: decode failed for 32453

That's expected, that's the attempt at decoding the value from the grouped read. But later on there is:

2023-11-08 15:24:16.025 DEBUG (MainThread) [custom_components.idm_heatpump] raw value (uint16) for zone_1_room_3_mode: 1

That's the second decoding from reading the register for zone_1_room_3_mode on its own. AFAICT that reads the value you expected.

[daemonenstall]

My bad. But now something else is going wrong. The room modes that have failed with the crazy values before, are now working fine. But all other ones are always off (eg zone_1_room_2_mode: 0). Maybe the room mode registers really have to be read alone. As far as I have understood (decode failed for zone_1_room_3_mode, retrying with single fetch), you are only fetching the registers alone if the interpretation fails. home-assistant_idm_heatpump_2023-11-08T18-33-13.831Z.log

[AndyNew2]

Seems like that, will try mine and report. I already suspected, the room mode 0 is just by chance interpreted correctly but still read wrong. Performance wise, how big is the draw back, when the room modes needs reading extra?

[AndyNew2]

Just checked, have exactly the same behaviour like daemonenstall. All values showed before "Unbekannt" are now correct and the other ones are still showing wrongly "off".

[AndyNew2]

@daemonenstall Is there a way to exchange directly messages? I like to clarify the NavigatorPro issues we experience, however that may be not interesting in that context...

[kodebach]

I released v0.5.0-beta06. It still doesn't load all room modes individually, but it always starts a new grouped read at the room mode registers. I did it this way, because I suspect, the heat pump checks the start address in the request and that triggers some special logic for the room mode. Let's see if it works this way, otherwise, I'll read the room modes individually.

Performance wise, how big is the draw back, when the room modes needs reading extra?

The original reason why I introduced the grouped reads was to reduce the number of requests and thereby reduce the chances for the weird failed reads that sometimes happen. But it does also improve the performance somewhat. However, loading every register one by one still only takes a few seconds. So with the minimum refresh interval of 1 min you'll never actually see a real difference.

Is there a way to exchange directly messages? I like to clarify the NavigatorPro issues we experience, however that may be not interesting in that context...

Not a direct message, but if you don't mind the discussion being public, you could create a new discussion thread. I enabled the Discussions feature, exactly because I wanted to give people to talk about things (somewhat) related to the integration, which aren't bugs or feature requests.

[daemonenstall]

@kodebach For me now everything is working. 👍 @AndyNew2 No problem. You can contact me via daemonenstall at gmail.com and then we can find a way how to get in touch.

[AndyNew2]

Beta6 works perfectly. All good now. I tested also setting rooms to "Normal" and "Eco" All shown now in the idm integration in Home Assistant. Great work. Ready to release in my opinion...

[kodebach]

I released v0.5.0 with an additional option (when you (re-)configure the integration) for reading all sensors without grouping.