Nilan Compact P Air 9 support

[SalifTraoure]

Hi,

I have a Compact P Air 9 unit with CTS602 control.
Any plans to support this unit any time soon ?

I have the communication set up to HA and read the following data.
HW ID: 16
Application id: -32756

I was emailed the attached mapping by Nilan to be the correct one ( althought the document states : 32780=combi).
I haven't challenged them on it being wrong. Most registers seems to be correct.

( Although date and timers decoding is a challenge for a newbie like me ). That's why I was hoping my unit would be supported.

CombiController_RemoteModbus v4.pdf

[veista]

Follow the instructions in the read me file is the plan.

[SalifTraoure]

Enabling debugging mode for HACS and reproducing the setup doesn't seem to produce anything in the log.
I get the feedback "Unsupported Device". See attached photos for instructions given in readme.
Sorry for not noticing those..

home-assistant_hacs_2024-01-11T21-53-43.413Z.log

[veista]

I need a picture of the HMI showing the device name. You should enable debug logging for nilan integration, not HACS. Read previous issues and conversations.

[veista]

That is the right page on HMI, Your model seems to be different from all the others in that regard, Enable the logging and let's see what that brings up.

[veista]

PS. If it was not obvious to you, do not have your own modbus instance running while trying to communicate via this integration.

[veista]

I added support for your device in the latest beta. Be sure to have betas enabled in HACS if you are using HACS.

Please do the following:

1. Report your modbus version shown by the integration
2. Report any unresponsive/non-working entities
3. Cross-check all functionality with the HMI panel

[SalifTraoure]

T35 works fine when I read it manually as a modbus sensor with my own YAML.

I did my best to hightlight the registers I believe is relevant in the attached pdf.
Green: 1st priority

• Basic data

• needed for my troubleshooting / diagnostic

Yellow: 2nd priority

• Convenient, but strictly not necessary
  Alarms, Timers

CombiController_RemoteModbus.v4.pdf

I am not 100% sure it is the correct document although this was the document I received from Nilan support when I struggled to find the right one online. My device reports : Application ID 32756, whilst the document states application id:32780=Combi.
I will ask Nilan to be 100% sure, but in my experience they take weeks to answer.
From reading back values - it seems to be correct though...

The only thing I don't understand is the "setpoint" for central heating - water circuits. In support they reverted to me and said I should use holding register 1802 if the mode was compressor minimum. But reading back 1802 it doesn't match with HMI, so I'm struggling with this.

Regarding the updated version - Still no climates. Still 32 entities which are sensors. Same as before.
Logs look the same as well.

[veista]

Are you 100% sure you tried 1.2.13B2 version?

[veista]

Those alarm code implemtations might be really tricky. Otherwise should be straight forward once the basic functionality works.

[veista]

Also you might have to "re-install" after update.

[veista]

Ok. I see the issue. Your hw type is 44, not 16. This complicates things immensly. I will try to figure something out...

You can test this by using version 1.2.12. If it "works" then that is the issue.

[SalifTraoure]

Register 5 reports 16 which should be HwID. Where did you detect HWid 44?
I can ask Nilan for clarity if in doubt

I tested version 1.2.12 ( reinstall custom Nilan integration and restart HA --> add device). Same result. Same 32 entities. Only sensors.

[SalifTraoure]

Yes, I am using HACS.
I will refresh my memory on how to actually do debugging. ( like you say - enable it config.yaml)

[SalifTraoure]

I might have been fooled by the HACS / Nilan stating updated 4minutes ago when I reinstalled.
I will try the manual installation of the latest pre-release in an hour or two. Need to get some kids to bed.

I will add the following to configuration.yaml in addition.
logger:
default: critical
logs:
# log level for a custom integration
custom_components.nilan: debug

[veista]

Ok, so now I added the debugging strings to release 1.2.13B4

[SalifTraoure]

Good news. No errors. 104 entities appeared.
I think I spotted one value that seems to read the wrong register. I will go through and update later tonight.

home-assistant_nilan_2024-02-06T18-53-28.715Z.log

[SalifTraoure]

I did basically a full check of all values listed in the home view. Some scaling findings - registers seems to be correct. See attached png.
I did some few corrections to some descriptions ( could also be mistake in the local HMI :-) - so don't bother to update descriptions if it matches document)

As for the other settings amongst the 104 entities that appeared - I didn't check them.
But the ones I checked seemed ok.
Just one unit mistake on ventilation time reported as seconds should be minute - But doesn't really matter.

EDIT - deleted humidty part - all ok. Understood the setpoint being the threshold for low humidity setting.

[SalifTraoure]

1 more observation

Is it a quick fix to add the FC voltage reading? , IR1925, ( Scale 0.1 - checked)

[SalifTraoure]

Edit: alam - misunderstanding..

[veista]

I think you misunderstand. That does not show hps alarms, only the indoor unit alarms.

[SalifTraoure]

Understood. Thanks for clarifying. I also edited / deleted the comment about fan controls in case you read it. I realized it was incorporated in the climate module.

[veista]

I made a new release for you to try on sunday. Did it fix your issues?

[SalifTraoure]

Hello again. All good with the latest release! I consider this to be a fully functional integration! 3 more entities was added. GEO alarm and Voltage as per my request. Thanks a lot.
I guess the GEO/AIR alarm reset command is a separate HR which you could consider to add in the future for consistency.

The only other observation which I don't necessarily think is wrong is the efficiency going beyond 100%. I guess this is a calculation (maybe affected by the amount of duct going inside my house for supply air affecting the calculation...? )
Anyway - it's not something I would care to monitor. Just to mention it..

Value check - both BETAs.

[veista]

Yes efficiency is compared to electricity 1000W electricity gets you 2000 W of heat -> efficiency 200% it is silly, I know. I can try adding the alarm reset, all alarms seem simple.

[veista]

Once you get the alarms active, read the hps alarm id registers contents.

[SalifTraoure]

Got one alarm - See readings as follows:

Alarms follow the Software guide (page 45 - 47)

Software - NYESTE - 2021-06 S24 Compact P AIR DK.pdf

Let me know if I can contribute in any way by putting the alarm id's / descriptions / guidance into any format. I guess I would look into adding the guidance ( 3rd colum ) - into the description - to have the guidance on what to do than rather just the name of the alarm.

[veista]

https://github.com/veista/nilan/releases/tag/1.2.13B6

[veista]

Can you test if the reset logic works with hps errors? I won't merge to master until you say it works, thanks.

[SalifTraoure]

Thanks. I was absent on winter break last week. Installed today. Will try to provoke an alarm. I didn't see any change in number of entities (106) so I guess you created the reset logic to reset both GEO/AIR and HVAC alarms through a common function ? ( although I believe it was two different registers)

[veista]

Should come up as its own entity. Reset AIR/GEO Alarm

[veista]

Can you check the logs for any errors?

[SalifTraoure]

I deleted the configuration. Updated all the files from B6.
Reinstalled the integration.
I thought this was sufficient. But it seemed a reset did the job. Now showing 107 entities and the AIR/GEO reset.

The debug revelealed another error
2024-02-24 16:40:07.138 ERROR (MainThread) [custom_components.nilan.device] Could not read get_external_heating_offset
home-assistant_nilan_2024-03-05T15-36-15.432Z.log

Am I missing another offset?

[veista]

Hi,

Great.

That means that your device does not physically have that register or just some error occured reading it. I will disable the entity for your device.

[veista]

How many occurances does the error have?

[veista]

BTW the entity that had that single error was "Room Temperature Neutral Zone", I think that is just a regular read error.

[SalifTraoure]

Hi. Finally managed to provoke an alarm. The reset seems to be working! Well done!
I do sometimes have to try several times and give it like 20 seconds to react. If I tried to quick I would get error message like you can see in screenshot (at the bottom). I guess it is a combination of Modbus polling delay effect that is natural. I also have this somewhat tricky behaviour when resetting the alarms from the local display by having to try multiple times, It may be an issue/bug with my firmware in the way it's processing alarms.

Is the reset code checking whether the alarm is 'inactive - and 'ready to be reset' - or if it is still active and cannot be reset?
I noticed this from the local HMI which reports them as 'inactive' (I guess this is the IR1602)

In an attempt to see the timing for when the alarm came in I was also looking in the logs to see if the Alarm ID was recorded anywhere else than in the Reset command window - like in the logbook. With 2 alarms incoming I was curious to see which one came first and if the second is a domino effect. I could not see an entry in the logbook but could see the rising edge in trend for active alarms. Also for troubleshooting and seeing patterns I get no record of which alarms that have been seen unless I keep a manual record on the side once I reset them. (It would be good to be able to document and show alarm patterns to Nilan for a support purposes)