no device nor entity during setting new integration / keine Geräte oder Entitäten gefunden während Setup der Integration

[adobe-hills]

I own a Weishaupt WWP 11 S ID heat pump. I also own the NWPM-N module from Weishaupt. This is probably a newer network module, which I has only very few settings. I can access the heat pump via the WEB interface and have set Modbus/TCP there. However, it is not possible to enter a port or an IP/IP range. Neither via the web interface nor via the WPM 6.0. There is also no point in the expert mode for this topic.
However, I can establish a connection to the heat pump via port 502 using the "MTCP" APP and can read out and get data. If I read out the next 20 available registers from register 1, I also get 20 values. I cannot interpret the values, but I get an answer. The Modbus interface should therefore respond.
However, when I include the integration in HA, I get no entities. No matter which entries I start with.

Maybe I oversaw something in the documentation and did something wrong. I tried to find a solution, but ended up to ask here for help.
Thank you so much!

attached you find the LOG of the attempt to add a new entry to the integration. Also a HCP from the integration.

GERMAN
ich habe eine Weishaupt WWP 11 S ID Wärmepumpe. Dazu habe ich das NWPM-N Modul von Weishaupt. Dies ist wohl ein neueres Netzwerkmodul, bei dem ich sehr wenige Dinge einstellen kann. Ich komme über das WEB Interface auf die Wärmepumpe und habe dort Modbus/TCP eingestellt. Es ist aber kein Eintrag für einem Port oder eine IP/IP Range möglich. Weder über das Webinterface noch über den WPM 6.0. Es gibt auch keinen Punkt im Experten Modus dafür.
Allerdings kann ich über die APP Mtcp eine Verbindung zu der Wärmepumpe über den Port 502 herstellen und kann Daten auslesen. Wenn ich von Register 1 die nächsten 20 verfügbaren Register auslese erhalte ich auch 20 Werte. Ich kann die Werte zwar nicht deuten, aber ich bekomme eine Antwort. Von daher müßte die Modbus Schnittstelle reagieren.
Wenn ich die Integration in HA einbinde, bekomme ich jedoch keine Entitäten. Egal mit welchen Einträgen ich starte.
Vielleicht habe ich auch etwas Wichtiges in der Dokumentation übersehen.

VIELEN DANK 😀

Hier findet ihr das LOG von dem Versuch einen neuen Eintrag zu der Integration hinzuzufügen.
WWP Integration.txt

[MadOne]

Do you still have no values?
After installation there is a refresh needed.
I cant see anything wrong in the log.

Even if the modbus part is not working the entitys should be created.

[adobe-hills]

MadOne, thank you so much for your answer. Unfortunately there are no devices or entities. Here are the steps I tried again this morning.

I deleted all and start with a new integration with DEBUG protocol.

all parameters I use you find in this Hardcopy. (I tried it also with BiBlock JSON. After I restarted the whole system

after the new integration it looks like nothing happened

[MadOne]

Did you do a Page refresh?

[adobe-hills]

I fixed the error with the *pwoermap.png, but still the same.

[MadOne]

I think your ip is incorrect. Missing dot before the last 2

[adobe-hills]

in the HC of the integration it is correct, but you are right in the first HC it is incorrect.

Weishaupt didn`t support the WEM anymore for new customers. So they changed the NWPM-N integration card to a new version. I have had bad luck with this brand new card, I need 4 pieces until the NWPM-N card was correct, all others dies within some hours.
There is also no user/password it is only a web interface. So I think this is the reason, I can´t use this integration, also maybe it is not possible to use the Experimental Web-Interface, because i find nowhere a token.

My web interface looks like this.

[MadOne]

This webif looks completely different. You are right.You cant use the experimental webif feature of our integration.

But if you can enable modbus you should be able to use our integration.
I have no clue why no entitys are created. This should ALWAYS work.

Can you confirm you did a page refresh at the integration page?

[adobe-hills]

yes, I can confirm this. I tried the integration now so many times and do it always. Refresh or reload (F5 or CTRL+F5 I used both)

With this new card I can only set Modbus/tp but no way to set a port or a destination. If I use a Modbus viewer I can access registers of the WWP.

[MadOne]

This is weird.

@OStrama : Any clue what is going on here?

[OStrama]

If the interface changed completely, I'm not sure if they also changed the Modbus addresses completely. There's a file called test_modbus.py. Could you please start this at the command line and share the result file?

[adobe-hills]

Sorry, I am not so familiar with Python. I added PY_modbus but still get some errors. I will try to setup a running environment this evening, because I am away from home and it is hard to find the solution if you aren`t at your computer. So sorry about this.

This is still the error I have.

C:\Users\Adobehills\Downloads>py test_modbus.py
Traceback (most recent call last):
File "test_modbus.py", line 5, in
from pymodbus import ExceptionResponse, ModbusException, pymodbus_apply_logging_config
ImportError: cannot import name 'ExceptionResponse' from 'pymodbus' (C:\Users\Adobehills\AppData\Local\Programs\Python\Python37\lib\site-packages\pymodbus_init_.py)

[adobe-hills]

looks not like the modbus/tcp is functioning.

C:\WINDOWS\system32>py c:\Users\Adobehills\Downloads\test_modbus.py >> modbus.log
c:\Users\Adobehills\Downloads\test_modbus.py:102: DeprecationWarning: There is no current event loop
loop = asyncio.get_event_loop()
2025-01-20 15:30:39,051 DEBUG base:56 Connecting to 192.168.2.222:502.
2025-01-20 15:30:39,051 DEBUG transport:242 Connecting comm
2025-01-20 15:30:39,056 DEBUG transport:277 Connected to comm
2025-01-20 15:30:39,171 DEBUG transport:386 send: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x4 0x75 0x31 0x0 0x1
2025-01-20 15:30:39,177 DEBUG transport:329 recv: 0x0 0x1 0x0 0x0 0x0 0x3 0x1 0x84 0x2 old_data: addr=None
2025-01-20 15:30:39,177 DEBUG base:91 Processing: 0x0 0x1 0x0 0x0 0x0 0x3 0x1 0x84 0x2
2025-01-20 15:30:39,177 ERROR pdu:128 Exception response 132 / 0
2025-01-20 15:30:39,177 DEBUG base:101 Frame advanced, resetting header!!
2025-01-20 15:30:39,177 DEBUG transport:386 send: 0x0 0x2 0x0 0x0 0x0 0x6 0x1 0x4 0x75 0x32 0x0 0x1
2025-01-20 15:30:39,181 DEBUG transport:329 recv: 0x0 0x2 0x0 0x0 0x0 0x3 0x1 0x84 0x2 old_data: addr=None
2025-01-20 15:30:39,181 DEBUG base:91 Processing: 0x0 0x2 0x0 0x0 0x0 0x3 0x1 0x84 0x2
2025-01-20 15:30:39,181 ERROR pdu:128 Exception response 132 / 0
2025-01-20 15:30:39,182 DEBUG base:101 Frame advanced, resetting header!!
2025-01-20 15:30:39,182 DEBUG transport:386 send: 0x0 0x3 0x0 0x0 0x0 0x6 0x1 0x4 0x75 0x33 0x0 0x1
2025-01-20 15:30:39,186 DEBUG transport:329 recv: 0x0 0x3 0x0 0x0 0x0 0x3 0x1 0x84 0x2 old_data: addr=None
2025-01-20 15:30:39,186 DEBUG base:91 Processing: 0x0 0x3 0x0 0x0 0x0 0x3 0x1 0x84 0x2
2025-01-20 15:30:39,186 ERROR pdu:128 Exception response 132 / 0
2025-01-20 15:30:39,186 DEBUG base:101 Frame advanced, resetting header!!
2025-01-20 15:30:39,186 DEBUG transport:386 send: 0x0 0x4 0x0 0x0 0x0 0x6 0x1 0x4 0x75 0x34 0x0 0x1
2025-01-20 15:30:39,190 DEBUG transport:329 recv: 0x0 0x4 0x0 0x0 0x0 0x3 0x1 0x84 0x2 old_data: addr=None
2025-01-20 15:30:39,190 DEBUG base:91 Processing: 0x0 0x4 0x0 0x0 0x0 0x3 0x1 0x84 0x2
2025-01-20 15:30:39,191 ERROR pdu:128 Exception response 132 / 0
2025-01-20 15:30:39,191 DEBUG base:101 Frame advanced, resetting header!!
2025-01-20 15:30:39,191 DEBUG transport:386 send: 0x0 0x5 0x0 0x0 0x0 0x6 0x1 0x4 0x75 0x35 0x0 0x1
2025-01-20 15:30:39,194 DEBUG transport:329 recv: 0x0 0x5 0x0 0x0 0x0 0x3 0x1 0x84 0x2 old_data: addr=None
2025-01-20 15:30:39,195 DEBUG base:91 Processing: 0x0 0x5 0x0 0x0 0x0 0x3 0x1 0x84 0x2
2025-01-20 15:30:39,195 ERROR pdu:128 Exception response 132 / 0
2025-01-20 15:30:39,195 DEBUG base:101 Frame advanced, resetting header!!
2025-01-20 15:30:39,195 DEBUG transport:386 send: 0x0 0x6 0x0 0x0 0x0 0x6 0x1 0x4 0x75 0x36 0x0 0x1
2025-01-20 15:30:39,199 DEBUG transport:329 recv: 0x0 0x6 0x0 0x0 0x0 0x3 0x1 0x84 0x2 old_data: addr=None
2025-01-20 15:30:39,199 DEBUG base:91 Processing: 0x0 0x6 0x0 0x0 0x0 0x3 0x1 0x84 0x2
2025-01-20 15:30:39,199 ERROR pdu:128 Exception response 132 / 0
2025-01-20 15:30:39,199 DEBUG base:101 Frame advanced, resetting header!!
2025-01-20 15:30:39,202 DEBUG transport:386 send: 0x0 0x7 0x0 0x0 0x0 0x6 0x1 0x4 0x75 0x37 0x0 0x1
2025-01-20 15:30:39,205 DEBUG transport:329 recv: 0x0 0x7 0x0 0x0 0x0 0x3 0x1 0x84 0x2 old_data: addr=None
2025-01-20 15:30:39,206 DEBUG base:91 Processing: 0x0 0x7 0x0 0x0 0x0 0x3 0x1 0x84 0x2
2025-01-20 15:30:39,206 ERROR pdu:128 Exception response 132 / 0

[OStrama]

That looks great! After a while the script should be ready and a file called register.txt should have been created. It should look like this:
register.txt
Could you show me your file?

[adobe-hills]

OStrama,

thank you so much for your help. Unfortunately my register.txt is empty 😥

Binary out

Binary in:

Input Register:

Holding Register:

register.txt

[adobe-hills]

I opened a request with Weishaupt. Usually they are really slow with responding. I hope I get a complete documentation of all registers.

I also try to find a Dimplex factsheet. All the heatpump before 2024 are from Dimplex and are only labeled to Weishaupt (Plus some nonsense things they add to the machine).
So usually the integration should be named DIMPLEX 🤣 also for most of the Buderus heatpump.)

I keep you up to date, if I have any answer.

[adobe-hills]

I found this website, but I am not sure if this help. This is the my modul original from Dimplex with the modbus parameters. In my case it is the WPM-M Software. Looks for me it is a big difference which WPM Software Version is installed.

https://dimplex.atlassian.net/wiki/spaces/DW/pages/3303571457/Modbus+TCP+Anbindung

[OStrama]

Had a look at the Dimplex Wiki: This is a completely different interface than our Weishaupt heatpumps use. Not only the addresses are in a completely orther range, but also the semantics is different.
So I'd say that it unfortunately would not make too much sense to put this all in one integration. Additionally, testing would be hard for us since we do not own an appropriate device.
Maybe, there are other projects out there that deal with this IF, like this for example: https://community.home-assistant.io/t/dimplex-heatpump-ls-8-as-nwpm-integration-using-modbus-tcp/722188

[MadOne]

As far is i know all "older" weishaupt heatpumps are from Dimplex. But weishaupt uses their own controller. So there is a chance this works. I can remember someone here with also a sole heatpump that worked. But i dont know witch version.

Anyways:
If the heatpump is responding our scan script should have found some valid registers. The Dimplex example was in 5xxxx Range witch we scan.

The Integration should generate devices and entitys. Even with NO heatpump or valid ip address the intigration behaves like this.

[adobe-hills]

I will also try the modbus files from the Dimplex heatpump OStrama present me.
The register.txt from yesterday evening shows that the register from 1 to 5194 have some life.
This is the range this Dimplex group use and also the range Dimplex show in the Wiki.

I'll stay in touch with you. Thanks you both so much for your help.

[MadOne]

This script scans ALL possible modbus registers. You get ":128 Exception response 132 / 0"

[MadOne]

I modified the script to print out the exception response. Can you please download the new script and run it?
The response will be printed to the console, not the file.

[adobe-hills]

I already did this yesterday evening. Enclosed you find the register.txt file.
I will run it with your latest file also, but it takes until noon, because I'm away from home.

register.txt

[adobe-hills]

the only difference in the test_modbus.py file is line 37. This is correct?

[MadOne]

Correct. this should print out the ModbusException to the console.

Can you please link the app you are using?

We are using this adresses.

[adobe-hills]

HI, I use Python 3.13 / 64 bit.
Enclosed you will find the console output as txt file
Thx

output WWP_S_11_ID.txt

[MadOne]

Im sorry, i messed up. Please download the file again (more changes) and run it.

[adobe-hills]

MadOne, her is the output of your test_modbus.py command file.

output__wwp_s_11_id.txt

For my understanding (I never did any modbus things before in my life), I found nothing in this output file, everything for me looks empty.
Than I changed the test_modbus.py file to the registers 1-5200. Here I think there are some more information (but I have no understanding of his materia) .This registers I found in this Dimplex wiki a named before.

Register 1-5200.txt

[OStrama]

Could you please also provide register.txt from the last run, if it's not empty?

[adobe-hills]

Hello @MadOne, hello @OStrama
I have now executed the two scripts again. The registers between 30001 and 49999 are probably actually not used. The lower registers, which I also read from the Dimplex page, probably agree, because yesterday evening I started to familiarize myself with the Modbus topic and read out five stops. I'll include a hard copy below. I also add the two indexes?????. txt that I read out with your test_modbus.py.

Now I have a question, because I had no contact with programming at all in life. Can't you adapt a certain customer file in your integration and include it in the integration by mapping the registers to each other. So something like this:

Register Hot Water = Register No abc
Register Heating Flow = Register No xyz
Register Heating Return = Register No uvw
.
.
.
. and so on.

Then you would only have to adapt this register file for a special heat pump and theoretically you could integrate every heat pump into HA. This doesn't even have to be done by you, but something like a custom_list that the respective user could adapt to his needs. He only has to maintain the mapping file. If the integration with this special heat pump is then running well, it could then be offered in a selection window of your integration so that everyone with the same heat pump does not have to do twice the work. Probably just a dream of a non-programmer or maybe there is, or in my ignorance I don't see this.

In any case, I really want to thank you for the great effort you have with this software and especially for your patience with me.
THANK YOU

register_1-5200.txt
register_30001-49999.txt

[OStrama]

Wow, great that it also works in general with the completely different addresses!

So you probably understood a bit the content of hpconst.py. I'll add some comments for better understanding...

Are you willing to take part on the development of this integration by creating and testing the sensor entries for your type of heatpump?

Simple idea how to integrate this:

• Add a drop-down list of two heatpump types in config dialog.
• create different variables DEVICELISTS plus their entries
• choose one of them according to heatpump type

I'd rather not use configuration files since they would allow a lot of mistakes and we have limited ressources to support all of them ;-)

[adobe-hills]

There seems to be a small misunderstanding. I used the standard Modbus functionality yesterday, not your integration.

Of course, I will help if I can, also I get a functioning integration too. . I will now adjust the hpconst.py with my registers and then test it. Then we will see how far we can get with the first attempt. Maybe that Weishaupt only used different registers with the same values behind them as with the BiBlock.
What do you think? Maybe I need two days, because I have some appointments today and tomorrow.

[adobe-hills]

could you please share me the plain list of the BiBlock register. Maybe it is easier to map the corresponding Reigisters from mine.

[OStrama]

I updated hpconst.py. It's mainly about the ModbusObject constructors. The parameters are described here:
Every list contains of some ModbusItem objects that have a constructor with the following parameters:

address: The Modbus addres as it is mentioned in the heatpump's documentation
name: The entity name. Please note: This entry today only is used to automatically generate translation files.
It will be removed in future versions
mformat: One of the formats defined in FORMATS as they are TEMPERATUR, PERCENTAGE, NUMBER, STATUS or UNKNOWN
The format is used to control the conversion of the modbus register entry to the entity variable and back
mtype: The type of entity. Currently supported are:
SENSOR: A standard sensor entity
SENSOR_CALC: A "calculated" sensor. That means, the content of this entity is derived from other entities
of this integration. The definition of the calculation is done in params
SELECT: A select entity
NUMBER: A number entity. The value of this entity can be changed by the user interface
NUMBER_RO: In principle, this is also a number entity that ir writable. But to avoid damages at the heatpump
we decided to make this entity read only.
device: The devise this entity is assigned to. Devices are used here to group the entities in a meaningful way
params: Parameters to control the behavior of the entity, see description of the params lists
translation_key: The identifier that points to the right translation key. Therefore, the files strings.json and the
language specific files in the subfolder "translations" have to be up-to-date

Parameter lists look as followws:
all of the entries are optional on general
"min": The lowest allowed value of the entity that can be set by the user if read/write.
Not needed for SENSOR, SELECT, SENSOR_CALC
"dynamic_min": The translation key of another entity of this integration. The content of this entity will be used as min val
"max": The highest allowed value of the entity that can be set by the user if read/write.
Not needed for SENSOR, SELECT, SENSOR_CALC
"dynamic_max": The translation key of another entity of this integration. The content of this entity will be used as max val
"step": the step when entity is r/w, values can only be set according this step
"divider": On modbus, values usually are coded as int. To get the real float number,
the modbus value has to be divided by this value
"deviceclass": one of the SensorDeviceClass entries of HomeAssistant definition
"precision": number of digits after the decimal point
"unit": the unit of the sensor. When ever possible, use one of the pre-defined units of HomeAssistant
"stateclass": one of the SensorStateClass types to control storage of the entity in the recorder database
"icon": The icon name as it is used in Home Assistant

For SENSOR_CALC only:
"val_1" .. "val_8": translation keys of other entities that should be used to calculate the value of this entity
"calculation": A string that can be used by the eval() command to calculate the sensor value. All Python operations
and the variables val_0 .. val_8 can be used here
The value of the modbus address of the entity itself is available in val_0

[OStrama]

Ah OK, understand.. I do not have a plain list, but only the Excel file mentioned in the comments of hpconst.py

Feel free to test when ever you have time, this is a hobby project for all of us ;-)

[MadOne]

Hi,

so this looks like your heatpump has not the modbus register scheme the other weishaupt heatpumps have.
In principial we have a file (hpconst.py) where the registers are definded. You can try to modify this to your needs but you will propably run into some problems.

You can configure modbus and so also your heatpump in HomeAssistant like descibed here:
https://community.home-assistant.io/t/weishaupt-heatpump-integration-via-modbus/436823
https://www.home-assistant.io/integrations/modbus/#:~:text=The%20modbus%20integration%20supports%20all%20devices%20adhering%20to,connection%20combined%20with%20one%20or%20more%20TCP%20connections.

This integration was created so that users do NOT have to mess witch configuration files.

I suggest you use the modbus integration and create configuration suited to the needs of your heatpump.