Closed gllmlbrt closed 1 year ago
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.
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 ?
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
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.
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
Can you please supply the picture of the type plate of your device?
Few comments up I did provide the info on it, but see picture below:
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.
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.
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
Hi, so just to clarify: you can not change these at all, or just not with my integration?
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.
Ok, thanks. I will wait for your detailed list and take a look at your mqtt implementation.
I took a look at your code and the climate entity should work as expected and it also looks like that.
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
Hmm. That is interesting. Can you try removing all attributes from device.py from your device except where it reads "climate" and try again
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)
Ok. I will need to edit the code to get to the bottom of this. Thanks.
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 ?
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.
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.
So for the entity by entity pointers, if I do not comment on an entity that means it shows as expected, here we go:
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).
Yes indeed, that is why this is so weird. Those should work just fine as is.
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-
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...
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:
Yes, don't forget the comma at the end.
I figured out why you still get the invalid address error. Your device doesn't have hardware version available.
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.
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
Ok, I will wait that you try the QModMaster and keep making the integration more compatible with your device.
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.
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...
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.
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.
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.
Also I forgot to mention that you have to restart HA every time you make changes to code, if you did not realize.
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.
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.
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.
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.
It does indeed work better. However, before I start opening other issues for smaller things:
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:
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.
You can try things yourself with qmodmaster. Then you will see which registers actually work on your device.
As to 1. There are still bugs on climate entity which affect your model. Will try to fix.
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?
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.
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).
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?
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".
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?
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".![image](https://user-images.githubusercontent.com/58825251/204530168-364c06b6-7faa-4bb1-9f4d-61ab81710e94.png)
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