New Device Nilan Comfort 300 (Top) about nilan HOT 65 CLOSED

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.

from nilan.

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

from nilan.

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.

from nilan.

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.

from nilan.

Scanned one-by-on 1300 to 1399, not avaiable. "illigal".

from nilan.

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.

from nilan.

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 ?

from nilan.

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

from nilan.

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.

from nilan.

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

from nilan.

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

from nilan.

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

from nilan.

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.

from nilan.

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

from nilan.

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

from nilan.

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.

from nilan.

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

from nilan.

image

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

from nilan.

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

from nilan.

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

from nilan.

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)

from nilan.

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 ?

from nilan.

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.

from nilan.

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.

from nilan.

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).

from nilan.

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

from nilan.

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-

from nilan.

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...

from nilan.

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:

from nilan.

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

from nilan.

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

from nilan.

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.

from nilan.

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

from nilan.

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

from nilan.

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.

from nilan.

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...

from nilan.

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.

from nilan.

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.

from nilan.

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

from nilan.

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.

from nilan.

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.

from nilan.

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.

from nilan.

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.

from nilan.

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.

from nilan.

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

from nilan.

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?

from nilan.

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.

from nilan.

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).

from nilan.

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?

from nilan.

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".

from nilan.

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?

from nilan.

OK I will invetigate for an update...

input 114 and 115 are returning "illigal data access". So not available...

from nilan.

Hmm. Ok. I will add the led info for your model.

from nilan.

Last thing you could try is to read input registers in range of 1300-1399 and see if they work, that is why I am wanting an older manual.

from nilan.

I added a new release. Hope it works for you.

from nilan.

Thanks works all great, apart from still the missing climate entity with fan speed control which quite important.
Aside from the missing climate thing, I am confortable picking it up from here and forking it for myself for minor improvements etc... and even submit some PRs if useful.

But I would not know where to start for the climate entity...

from nilan.

I will fix this, sorry for it not working already.

from nilan.

I will fix this, sorry for it not working already.

Ahah !! why would you be sorry for that ! I was just wondering if I did something wrong...
Thanks so much for the help so far. I think this integration is far more elegant with direct modbus com than clumsy MQTT entities ! I will be patient, no worries and no urgency !

from nilan.

Ok, so can you test if input registers 1100, 1101, 1102 work with qmodmaster?

from nilan.

It should come up now, though I think register 1101 didn't work on your device so the status doesn't work as it is supposed to. If 1100 works I could replace it with that and also add that as a sensor.

from nilan.

So nothing on 1100, 1101 and 1102 do not read anything. Illigal.

My my previous config, it was all writtent and read from Holding register control.VentSet address 1003.
I worked jsut fine, and it works fine now when readind and writting with qmodmaster functions... Could that work, to have the 1003 Holding as a set and state ?

from nilan.

Hi, unfortunately that wouldn't work. I guess I can take the current release out of beta?

from nilan.

unfortunately that wouldn't work.

Hold on, I was able to have the climate entity in the first beta you made, and I could eventually perfectly adjust the fan speed, and it reported correctly as fan state... so why wouldn't be possible to have the same as at the beginning ?

from nilan.

Did you try the 1.0.14B?

from nilan.

Did you try the 1.0.14B?

Nope, I hadn't seen that you released one, but now I tried, and yes it all works like a charm ! Definitely can go out of beta...
I will fork from here if I feel it is needed.
Thanks a LOT !

from nilan.