Closed gllmlbrt closed 1 year ago
I can add some experimental entities for the ascii fields.
That would apply/work for all Nilan presumably...
Unfortunately only models without the touch panel. These registers have been removed after touch screen.
Qmodmaster is a great tool to debug and experiment the button presses. If you get it to work I can add a button entity category at some point.
Can you provide a sample for the ascii and other register values?
Well here is it from qmodmaster:
The display shows only 16 bits, and does not allow me to show all of them due to size, I suspect HA modbus integration could do that ?
But that is binary which should be converted to text... Not sure how else to get all of it out. BUt anyways converting what I can see, It matches what is written on the panel.
You can just show dec or hex
This is all meant to read"HEAT >1< 22C"
Added a new release.
Does the display sensor work as intended?
Hey, yes it works as to display whatever is being transmitted over MB, but unfortunately it is a bit messed up:
This is meant to read "AUTO L >1< 22C" I tried with other texts, it works well, but scrambled as well the same way, so it is a parsing order issue only... So the A and U are inverted, then the O and T are inverted, and > and 1 as well. Then there is this ß which I think is meant to be a degrees symbol... which means that the degrees symbol and the C and also inverted in order.
Here I managed to write to holding 2000, up and down to get to:
Which should read "SHOW ALARMS" which make it clear how the order is scrambled.
Technically there are two lines:
Here it should read "LANGUAGE" in the first line using all 8 characters, and "ENGLISH " using 7 characters and a space. Best example to show both lines, and the scrambling.
I am not sure what would be best, to keep all in one line, or have it as intended on two separate text, as separate lines, if I want to repriduce what the panel shows...
Better have it in two separate sensors/lines, I can always template them into one again if needed on some cards.
Made a new release for you to try. Yes was wondering about the byte order from your example and got it the wrong way around. It is funny that it is not ascii as stated in the datasheet, but instead HD44780, Nilan has taken a shortcut here. If there are more special characters outside of ASCII basic character set https://www.ascii-code.com/ let me know.
Perfect !
Ok. Adding the buttons may take some time.
You can try to improve the refresh rate by shortening the update interval from const.py . Be warned though, if it is too short you will face issues.
Added buttons for testing.
I don't seem to see anywhere any button entity created after several restarts, am I missing something ?
It should come up in control entities with version 1.0.17B
Sorry, realized the problem, I forgot to push a file.
New release available.
Actually found the correct Modbus manual for your device https://www.en.nilan.dk/Files/Files/Engelsk/Archive/Software%20instructions/2015-01%20CTS%20602_CTS602_Modbus_protokol_ver100.pdf
Thanks ! For the buttons, the on / off work great. For the up/down, it is strange, looking like if I press once, it goes up or down 2 or three steps... Now I have used it remotely (ot home), so I cannot check what is happening actually on the display at the system. Will check again when home tomorrow. BUt anyways, it looks like it is going up and down several steps...
And then the blonking is not at all visible when selecting a value for edit. Even with scan_internal=1.
Hi, Yes, I Guessed that might happen since I cannot control the off delay of the button. The action is repeated if not cleared in 400ms. That would have to be made similar to your MQTT device so you could control the button presses more precisely. I'm just wondering what the purpose of the HMI emulation is if all functions work as entities?
Also I would assume shotening the scan interval makes the buttons work worse, since it might not have enough time slots to send the button off message. That would also be random then how many times it pushes a button. It would be too much effort and convay away from the rest of the integration, so i will propably not add the buttons to the actual integration.
On another subject, do you still get the invalid address errors?
Realized also that your firmware version has also inverted byte order. Will fix this also.
Noted about the buttons, makes sense. It was more a nice to have rather than a need to have for sure. Yes, still get the error addres as follows:
Logger: homeassistant.components.modbus.modbus
Source: components/modbus/modbus.py:391
Integration: Modbus (documentation, issues)
First occurred: 3 December 2022 at 21:03:40 (14974 occurrences)
Last logged: 16:08:45
Pymodbus: Nilan: Exception Response(132, 4, IllegalAddress)
Pymodbus: Nilan: Exception Response(131, 3, IllegalAddress)
does not seem to affect any functionality though...
Hi added a new release, hope that this fixes the buttons - If not I will remove them, but you can always add them back if you like them. Hope the new version also fixes Firmware version on your model and removes - at last - the unsupported entities, so you wouldn't get those errors anymore.
Also, I read that Nilan does updates to the older models, so I would concider doing that in your case.
Contacted vendor for the update of my system. Haven't heard back yet. I suggest we close this issue and abandon the button thing. If someday I absolutely need that I can remotely connect with qmodmaster... Thanks for the try !
Should I open a separate issue for the illegal address error I get ?
Sure. I'm still trying to figure it out. I cross checked every register I read and still this issue remains. I have to be more thorough. Does the version read correct at least?
I am not sure what you mean by that ? The error is about an illigal address
Logger: homeassistant.components.modbus.modbus
Source: components/modbus/modbus.py:391
Integration: Modbus (documentation, issues)
First occurred: 3 December 2022 at 21:03:40 (14974 occurrences)
Last logged: 16:08:45
Pymodbus: Nilan: Exception Response(132, 4, IllegalAddress)
Pymodbus: Nilan: Exception Response(131, 3, IllegalAddress)
I am not sure what it is searching at those addresses, but acc. to my modbus protocol both 131, and 132 or 4 are inexistant addresses at both input and holding.
3 exists and reads fine as 652E (HEX). OK also with 0, 1 and 2.
Protocol:
Yes, indeed. The integration reads or writes to a non-existent address, which my device has, but yours doesn't. Just can't find the mistake in the code.
Ok, I found still one register that was read that is not supported <20 Bus version. Can you try it out?
Hi, could you provide me a picture of your panel from:
Ok, now finally found the last one. Should be fixed on 1.0.22B.
Definitely some improvement, now only the one left as below:
Logger: homeassistant.components.modbus.modbus
Source: components/modbus/modbus.py:391
Integration: Modbus (documentation, issues)
First occurred: 07:10:45 (2006 occurrences)
Last logged: 12:45:00
Pymodbus: Nilan: Exception Response(132, 4, IllegalAddress)
Image below for the type:
Thanks for the picture! Added some debugging to get to the bottom of this on 1.0.24B. The problem should show up in logs now.
Hi, so the logger you added seems to have had some results:
Logger: custom_components.nilan.device
Source: custom_components/nilan/device.py:787
Integration: Nilan (documentation, issues)
First occurred: 06:29:10 (301 occurrences)
Last logged: 07:19:11
Could not read get_control_temperature
Looking at the code it points to the "air_temp_temp_control" mapped in the register.pz twice at address 1202 and 3009. I can read off qmodmaster at 1202 OK, but nothing and error at 3009 (like all the display addresses).
And still of course:
Logger: homeassistant.components.modbus.modbus
Source: components/modbus/modbus.py:391
Integration: Modbus (documentation, issues)
First occurred: 06:29:10 (301 occurrences)
Last logged: 07:19:11
Pymodbus: Nilan: Exception Response(132, 4, IllegalAddress)
Thank You! Never would have guessed that the ModBus Manual has duplicate name entries, there were 3 in total.
Great ! Error gone with latest beta.
Thank you so much!
Hi again,
The actual text displayed on the CTS602 panel is transmitted over modbus at the following input addresses 2002 to 2011:![image](https://user-images.githubusercontent.com/58825251/205143319-c1b6f0c6-55cc-4fc8-abf3-e6ef4d0bffa5.png)
I had that working just fine over MQTT. So I could read exactly what what printed on the panel at the system, which is in a cabinet. Avoiding having to open the cabinet to verify, and was a good way to check immidate effect of the change of state etc... So I added it here:![image](https://user-images.githubusercontent.com/58825251/205144725-6110b4a4-279f-450a-b63a-c79156bdf11d.png)
Now also, key press can be written here at the following holding addresses:
That part I never managed to make work over MQTT.
But if both worked here, we could create buttons in lovelace reproducing exactly the panel and calling for service for modbus writing reproducing exactly the panel on a UI, and also having the whole complete menu available from HA.
That would apply/work for all Nilan presumably...
I could help working on this, but I might need a couple of pointer to have the text sent over the integration, and the method to write keypresses to holding reg.
If you think it is not useful, feel free to close the issue, and I might give it a long shot on my own as a fork.