New Device Nilan Comfort 300 (Top)

[gllmlbrt]

Hi, I think I got the Modbus bridge running, and now I get an error when trying to set up the integration through config flow. "invalid response from device".

I checked the logs, on debug mode and there is no entry for the custom integration. I suspect it is due to an unsupported device.

Any idea ? I do not have HMI panel. Only CTS602. Item No.: "71104F", Model: "Comfort 300 Top" from year 2015

[veista]

Hi, I think there is some error in your bridge, since you get a modbus error. You can turn modbus debugging on to see the specific error, but I suspect a timeout error.

[gllmlbrt]

Very possible that it is an issue with the modbus bridge. Now, you mention modbus debugging, do you mean that I should add the bridge in Home assistant with the Hass modbus integration ? I thought the Nilan custom integration connected directly to the bridge ? Or did I miss something ?

[veista]

Yes it does connect straight to the bridge, but it uses the internal modbus library, so you can just enable the debugging for homeassistant.components.modbus

[veista]

I suspect it is due to an unsupported device.

The integration will report unsupported device if communication is ok, but is not supported by the integration. You will then find a string in the debug log where your device id is reported.

[gllmlbrt]

OK, now that I used hardware serial on wemos D1, I get the following when trying to set-up the integration: 2022-11-29 20:00:55.741 DEBUG (MainThread) [custom_components.nilan.config_flow] Device Type 13 not found in supported devices list

[veista]

Can you please supply the picture of the type plate of your device?

[gllmlbrt]

Few comments up I did provide the info on it, but see picture below:

[veista]

Thanks, I collect the pictures, it helps if there are same ID:s on different devices and I need to debug that. I will add your device as soon as possible.

[veista]

I added initial support as a beta release. You will have to enable beta releases in HACS. Please report any entities that do not report valid values or entities that are missing.

[gllmlbrt]

Worked thanks ! Lot of entities are messed up, but that was expected. I iwll make a detailed commenting, and see attached the modbus protocol applicable for the comfort series. 2016-02-16_CTS602_Modbus_protokol.pdf I cannot control fan speed and set temperature and humidity from teh HVAC

[veista]

Hi, so just to clarify: you can not change these at all, or just not with my integration?

[gllmlbrt]

No it works fine to use the control features when integrated via MQTT and template entities (Typically climate template MQTT climate). Then fan step, set temp were all controllable just fine. So the issue appears only with the integration now.

[veista]

Ok, thanks. I will wait for your detailed list and take a look at your mqtt implementation.

[veista]

image

I took a look at your code and the climate entity should work as expected and it also looks like that.

[gllmlbrt]

Thank you, but jsut to be clear this screenshot was actually taken form your integration. So the look is indeed perfect and as expected ! All I ws saying is that the control input is not regristered. Say if I want to input a higher temp, or a different fan speed it does not wrok. LIke it is in read-only mode.

Here is the error log I get when trying for example to set a new fan speed: I checked the register addresses for control and they are all correct for this model as well. 100X

[veista]

Hmm. That is interesting. Can you try removing all attributes from device.py from your device except where it reads "climate" and try again

[gllmlbrt]

done. But the climate entity does not come back at all. Only this as a single device with a single entity (unavailable). And still this:

Logger: homeassistant.components.modbus.modbus
Source: components/modbus/modbus.py:391
Integration: Modbus (documentation, issues)
First occurred: 12:14:07 (2 occurrences)
Last logged: 12:15:40

Pymodbus: Nilan: Exception Response(132, 4, IllegalAddress)

[veista]

Ok. I will need to edit the code to get to the bottom of this. Thanks.

[gllmlbrt]

One additional question, I assumed perhaps wrongly that I should just leave the 30 as Unit ID when creating the integration in workflow, but I am not sure. No other number works... Is 30 ok ? Or what should be there ?

[veista]

30 is default unit id and it seems to work. I will try to fix the issues. They most likely come from differences between your model and models with touch screen HMI. The integration reads registries that your machine does not have.

[veista]

Now I'm not so sure anymore. I cross referenced the registers, though there are some missing from the document you provided, the alarm reset entity should not cause those kind of errors.

You could try adding the following line to the device.py: add "message_wait_milliseconds": 30, line after "delay": "",

Otherwise there must be still some kind of weird issue with the bridge: You can debug that with https://sourceforge.net/projects/qmodmaster/

In settings of qmodmaster use Base Addr 0, if it is something else.

If that works fine and you are able to write the holding registers without issues, then we will continue finding the problem.

[gllmlbrt]

So for the entity by entity pointers, if I do not comment on an entity that means it shows as expected, here we go:

1. 24h Average Humidity: It is not an item avaialble with this model, at least with this firmware version. Can be removed
2. Compressor: Not installed on the model Comfort, can be removed
3. Days Since and To Air Filter change: Should be shown, available at register 1103 and 1104
4. Fresh Air Intake Temperature: Shown as 0, it should be T8 on the comfort model (Not T1). It is at register 208, called "Outdoor Temperature"
5. Return Air Temperature: Should be T3, at register 203 called "Exhaust Temperature". The -40 shown is currently get T9 or T10 which are not used by the comfort model.
6. Waste Air Temperature: Should be T4 Outlet, at register 204, called "Outlet Temperature"
7. Return Fan Level and Supply Fan Level: should be available, both at 200 and 201 register in %, called respectively "Exhaust Fan Speed", and "Inlet Fan Speed"
8. Ventilation State: Shoudl be available. I think it has to be the "Run State" available at register 1000. It is a controllable item, so ideally a switch for on/off switching of the whole system.

Then there are all the Select, configuration items entities which I never had or bothered set-up with the MQTT integration. Would be nice to have if easily controllable (Write access).

[veista]

Yes indeed, that is why this is so weird. Those should work just fine as is.

[gllmlbrt]

Notably the Opened/closed state of the air bypass (letting colder air in bypassing the exchanger) is not reflected anywhere. Seems to be missing altogether, and is an item which seems to be only on the Comfort. It is as a 1:open, 0: closed at register 3000.

And finally, there is an extra feature which my model has which is a special "user func" connection, which is connect to the kitchen hood, there is is a on/off button activating the ketchen stove suction from the ventilation. That state is available at Register 600-

[gllmlbrt]

Now I'm not so sure anymore. I cross referenced the registers, though there are some missing from the document you provided, the alarm reset entity should not cause those kind of errors.

You could try adding the following line to the device.py: add "message_wait_milliseconds": 30, line after "delay": "",

Otherwise there must be still some kind of weird issue with the bridge: You can debug that with https://sourceforge.net/projects/qmodmaster/

In settings of qmodmaster use Base Addr 0, if it is something else.

If that works fine and you are able to write the holding registers without issues, then we will continue finding the problem.

Will give those two things a shot...

[gllmlbrt]

You could try adding the following line to the device.py: add "message_wait_milliseconds": 30, line after "delay": ""

Just to be sure you mean like that:

[veista]

Yes, don't forget the comma at the end.

[veista]

I figured out why you still get the invalid address error. Your device doesn't have hardware version available.

[veista]

I'll try to draft a new release for you to try. It starts to make sense, though I still don't understand why you can not write the holding registers.

You can remove the line self._device_hw_ver = await self.get_controller_hardware_version() from the device.py and see if there is still an error in the log.

[gllmlbrt]

Tried that and still get: Logger: homeassistant.components.modbus.modbus Source: components/modbus/modbus.py:391 Integration: Modbus (documentation, issues) First occurred: 20:08:27 (46 occurrences) Last logged: 20:09:16

Pymodbus: Nilan: Exception Response(132, 4, IllegalAddress) Pymodbus: Nilan: Exception Response(131, 3, IllegalAddress) Pymodbus: Nilan: Modbus Error: [Input/Output] No Response received from the remote unit/Unable to decode response

[veista]

Ok, I will wait that you try the QModMaster and keep making the integration more compatible with your device.

[gllmlbrt]

Additional clue, f that helps: When I reload the integration it then creates a whole new separate Device, automatically added to the "Boiler Room" area, which is an area I never had before, it is it seems an error created by the integration: The device has one entity the "select.nilan_reset_alarm". And if I re-relaod the integration, the device stays, but the entity is moved back to the correct device.

[gllmlbrt]

OK, now it works. After the two reloads, I can control the fan speed as expected, set the temperature and operation mode ! Not sure why ? So that'd indicate that the bridge is fine...

[gllmlbrt]

Aditional error: The climate entity appears to take the panel temperature as the current temperature, instead of the "returned air temperature" or Exhaust Temperature for my model.

[veista]

Additional clue, f that helps: When I reload the integration it then creates a whole new separate Device, automatically added to the "Boiler Room" area, which is an area I never had before, it is it seems an error created by the integration: The device has one entity the "select.nilan_reset_alarm". And if I re-relaod the integration, the device stays, but the entity is moved back to the correct device.

"Boiler Room" is just the suggested area by my integration. This happened to me once too not sure why. It went away once I deleted the Integration and added it again.

[veista]

Aditional error: The climate entity appears to take the panel temperature as the current temperature, instead of the "returned air temperature" or Exhaust Temperature for my model.

Hi, I guess this is a feature of your device. I noticed that earlier too and it confused me. The entity I read for that is room master temperature. If you look at your device manual the sensor is selectable on your device - panel, external or exhaust. You should change it to exhaust in your panel settings before I have time to add it to HA :)

Room master temperature is what the device actually uses for temperature control. That is why there is a separate Return air temperature in sensors otherwise I would have omitted it.

I have taken a convention to using terms Return, Supply, Intake and Waste.

[veista]

Also I forgot to mention that you have to restart HA every time you make changes to code, if you did not realize.

[gllmlbrt]

Also I forgot to mention that you have to restart HA every time you make changes to code, if you did not realize.

Yes, I did everytime. Uninstall integration, restart, re-download, modification to code, restart.

[gllmlbrt]

The entity I read for that is room master temperature. If you look at your device manual the sensor is selectable on your device - panel, external or exhaust.

Yes I was aware of that, and checked, I am 100% sure it is selected as "Exhaust", I just rechecked in the service menu again to be sure. now here on my device the exhaust temp is T3 at address 203. And not the return temp T9/T10 which I do not have.

[veista]

The entity I read for that is room master temperature. If you look at your device manual the sensor is selectable on your device - panel, external or exhaust.

Yes I was aware of that, and checked, I am 100% sure it is selected as "Exhaust", I just rechecked in the service menu again to be sure. now here on my device the exhaust temp is T3 at address 203. And not the return temp T9/T10 which I do not have.

You are right, this is a bug. I did not notice I was using the wrong register since on my device they have the same value.

[veista]

Hi, I added better support. There are still a few missing config entities, but you can test if this works better and you can open a new issue for those. Let me know how it works now.

[gllmlbrt]

It does indeed work better. However, before I start opening other issues for smaller things:

1. The climate entitiy is not created at all now. No Hvac despite restarting, reloading, redownling etc..
2. Return Fan Speed and Supply Fan Speed work perfect, but there is still the other entities "Return Fan Level" and "Supply Fan Level" which should both be removed.
3. Bypass flap shows "Unknown". I have had issues with this one myself for the MQTT integration... Is there something I should test ? I think I ended up coding based on the Display.LED_1, address 2000 as the User panel indicator which reflects the bypass flap position.
4. Waste Air Temperature is missing altogether now.

5. Days since and days to filter change still missing

Just a general clarifiation: I do agree your convention Supply, Return, Intake, Waste makes more sense and is better. However, I think they got mixed up with the convention used by nilan in the protocol:

• Outdoor Air, air sucked in from outside, INTAKE T8, address 208 "T8_Outdoor"
• Inlet, air blown into the room, SUPPLY, T2, address: 202 "T2_Inlet"
• Outlet, air blown outdoor, WASTE, T4, address: 204 "T4_Outlet"
• Exhaust, air sucked out of the rooms, RETURN, T3, Address: 203 "T3_Exhaust" Although the terms Supply and Return temparatures are used for central water heater systems. So really in order not confuse them we should perhaps consistently call them for the COMFORT Inlet, and Exhaust...

And finally, I still get:

Logger: homeassistant.components.modbus.modbus
Source: components/modbus/modbus.py:391
Integration: Modbus (documentation, issues)
First occurred: 06:39:00 (787 occurrences)
Last logged: 07:37:04

Pymodbus: Nilan: Exception Response(132, 4, IllegalAddress)
Pymodbus: Nilan: Exception Response(131, 3, IllegalAddress)
Pymodbus: Nilan: Modbus Error: [Input/Output] No Response received from the remote unit/Unable to decode response

Not sure if it matters at all.

[veista]

1. Try version 1.0.11B or remove line "get_ventilation_state", fom climate.py.
2. Ok. Manual suggested these would work.
3. I will try different things. There were 4 possibilities I think.
4. Will fix
5. I dont know why these do not work. Will remove.

You can try things yourself with qmodmaster. Then you will see which registers actually work on your device.

[veista]

As to 1. There are still bugs on climate entity which affect your model. Will try to fix.

[gllmlbrt]

I got QmodMaster working. I can read off input and holding registers just fine. Some few addresses however do not return anything, while they should... Example address 1103 and 1104 should be SinceFiltDay and ToFiltDay and I get error:

Otherwise all reading fine on the addresses 200s:

Anything you would like me to test that way?

[veista]

Well yes, what I tried to suggest that you cross match all the missing entities like bypass flap etc with your control panel and qmodmaster. That way I don't have to guess if something works.

[gllmlbrt]

OK, but I think it was all OK appart from thebypass flap. (And the climate entity issue).

And indeed, the addresses Holding 3000 is not accessible, possibly because reserved for the display panel. So instead we should use address 2000 in the Input Register which is accessible, which is a light that turns on when the bypass is opened =1 (light on) and closed=0 (light off). Device Class should be "opening". Binary sensor, name Air Bypass There is a way to control the bypass opening but this is not needed I think, as it is automatic for cooling.

And then there is this UserFunc Input Reg, at address 100 which is whether the kitchen hood vent is on or not. So you could name the binary sensor entity "Hood" , with device class "opening" (as it is an opening that opens when pressing the hood on button).

[veista]

Ok, so you can't even access input 3003? If not, that is another error. So can you read/write the holding register 102 and 103 for bypass control and status? That would be much better than reading a LED indicator.

Yes I can add the hood.

Yes I guess the manual you linked is for 2.37 -> and you have 2.03e device I could ask Nilan for an older manual.

For documentation purposes, can you read the value of input register 000 for me?

[gllmlbrt]

That's right, 3003 is not accessible either. I have tried 102 and 103 some time ago (for mqtt), and those are only to control. So they are always both on 0. If you input 1, it turn to open or closed position, remains on 1 during the move, and then goes back to 0. So it is not reflecting the position, but rather whether it is opening or closing, as in while moving. That is why I settled for the led light indicator... while it is not very elegant.

Granted that it is possible that 2.37 and later could have updated the addresses, so I am just not aware of the right address for my software version. Maybe I should ask a service technician to come over, update the firmware, and share the latest corresponding protokol for my system... Or do you know of a way to myself update the firmware ?

On register input 000, the BUS version is "7".

[veista]

Oh, That is old, mine is on version "22" My change log info ends on version "20". Unfortunately I don't believe you can update the firmware by yourself.

I wonder what are the input register 114 and 115 used for. Do these reflect the bypass?