Add support for therminator combi boiler (log wood + pellet)

[ragesoft]

Hi there, i just found your great repo! Is it possible to get this module working for my therminator II combi boiler? Can I use the module already now?

Based on the operation instructions there is a offset to use for the heating-circute readings of 200: https://www.solarfocus.com/produkte/Waermepumpe/EcoManager-t_Modbus-TCP-Registerdaten_Anleitung.pdf

:) Will look forward for this feature! i can test with my thermi II

[LavermanJJ]

Hi, great you like it!

The offset it currently not supported. In addition, the "Kessel" data is not yet supported. Everything else should be fine.

Am I correct, that you system is comprised of

• Heating circuit
• Buffer
• Kessel Right?

Let me try to add the Kessel information. However, as I have no means for testing, I'd need your feedback then ;)

[LavermanJJ]

Please try this beta release: https://github.com/LavermanJJ/home-assistant-solarfocus/releases/tag/v1.2.0-beta-4 Please make sure, that you enable "Kessel" or "Pelletsboiler" when adding the integration to your home-assistant instance. If you use HACS, please check the "pre-release" button, to see this beta version.

Looking forward to your feedback!

[LavermanJJ]

BTW, the states / modes are only displayed by their number. No text yet ;)

[ragesoft]

Oha... That was fast. Until now i'm missing the ModbusTCP setting. Solarfocus Support must activate it first... Than i can test ;) Thx!

[ragesoft]

I have installed the beta-4. I'm getting this error in log:

Unexpected error fetching solarfocus data: unsupported operand type(s) for &=: 'bool' and 'NoneType' Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 205, in _async_refresh self.data = await self._async_update_data() File "/config/custom_components/solarfocus/coordinator.py", line 54, in _async_update_data success &= True and await self.hass.async_add_executor_job( TypeError: unsupported operand type(s) for &=: 'bool' and 'NoneType' Config entry 'Solarfocus' for solarfocus integration not ready yet: None; Retrying in background

I cant add the "Senec" intigration as described in the docu, cant find it. is it nessesary for this component?

[LavermanJJ]

oh - that "Senec" one is a copy and past error :innocent: ... I rectified that. The error looks like there is no communication between home-assistant and the heating possible?

[ragesoft]

I can ping my thermi from SSH console on HA. I only setup the IP. I left the other both values (502 and 10 - dont know what this stand for) unchanged. Maybe something wrong with my Modbus TCP Settings on the solarfocus?

[LavermanJJ]

The 502 is the port that is usually used for Modbus TCP, and the 10 seconds are the interval home-assistant polls the data from your heating.

Could you please verify in your eco-manager touch that Modbus is ready? Should look something like the following (just that you probably have different "buttons" at the bottom.

Edit When configuring the integration, which elements did you enable? Only the ones present in your heating system?

[LavermanJJ]

... if I remember correctly, I had a similar issue when I initially set up Modbus with the heating. I could ping it, but Modbus wouldn't work. What solved the issue for me, was restarting the heating (power off/on). Afterwards, it was working fine.

[ragesoft]

I deleted and recreated the intigration. Now i only selected the "Kessel" option. Now i get readings. On the solarfocus itself, Modbus shows "Status 50003" and Function-Code 4

Readings wont get any values (beside there are "Pelletsboiler" instead of Log"

Unfurtunatly i cant restart right now. its currently working ^^ so i have to wait...

[LavermanJJ]

Unfortunately, I have no clue what that status code is. However, it seems that home-assistant is able to query it. The Function Code 4 is "read multiple input registers" which sounds good. Also the time since last query is < 10s which is the default query interval of this integration.

If the reboot helps to remove the red status code of the interface, I'd expect/hope that you receive valid readings. If on solarfocus side everything is green, but you still get invalid readings, it's due to this integration. If the error persists, you should check with the solarfocus support what this status code means.

[ragesoft]

Got feedback from support. The error code stands for "Invalid modbus mapping". I got a list of all status messages if u need it. (wont post here, maybe via some private message?)

:/

[LavermanJJ]

Would be great if you could send it to me via mail: banane.server_0u@icloud.com thanks!

Did the error persist after the restart? And did Solarfocus mention if it is caused by the integration?

[LavermanJJ]

I was wondering, what your eco manager touch version is? Currently the pysolarfocus lib queries Register 2400 + 11 registers which is valid for the latest version (202202). It could be, that due to an older version there are no 11 registers for the "Kessel" defined, hence, the error?

If you are familiar with python, you could clone the https://github.com/LavermanJJ/pysolarfocus repository, and adapt the respective constants?

[ragesoft]

My Kessel got Version 22.021

[ragesoft]

Maybe i found the issue! In your mappings, u have on line 244 "11" counts, but in the "PB_REGMAP_INPUT" object you only map 10 registers. And the address for "MESSAGE_NUMBER" is (based on found docu) "2404", u put there "2". All other registers adresses have to follow. there seems to be a gap between 2401 and 2404 :) (see this document: https://www.solarfocus.com/de/partnerportal/pdf/open/UGFydG5lcmJlcmVpY2gtREUvUmVnZWx1bmdfZWNvbWFuYWdlci10b3VjaC9BbmxlaXR1bmdlbi9lY29tYW5hZ2VyLXRvdWNoX01vZGJ1cy1UQ1AtUmVnaXN0ZXJkYXRlbl9BbmxlaXR1bmcucGRm/117920/0/Lng_YSxpM245S30zMTc4W2Y8cVRRXWlJVWRQJDsv?serialNumber=68905 )

maybe this is the problem? Greetings!

[LavermanJJ]

Correct - for the other items these gaps in the register numbers are not there in reality, therefore, I assumed they would not be there for "Kessel" as well. However, I tried to read out the registers with my system as well (even though I don't have a "Kessel"), and can confirm, that the gaps are there. In addition, the "2409 Kesselbetriebsart Therminator" seems not to be present

What did I do? I used plain Modbus to read out the registers:

from pymodbus.client.sync import ModbusTcpClient as ModbusClient

client =  ModbusClient(host="<...add IP-address...>", port=502)
client.connect()
result_input = client.read_input_registers(
            address=2400, count=12
        ).registers

print(f"Result: {result_input}")

This gives me (even without a Kessel) the following output: Result: [0, 6, 0, 0, 0, 0, 65535, 65535, 133, 1300, 1300, 0]

• 65535 equals -1 which seems to be the default for non-existent
• 133 is the outdoor temperature -> 13.3
• 1300 is according to the spec the value for missing sensor.

It would be great if you could try to run this python script and post the output here.

• copy the snippet in a file e.g. test.py
• install python3
• install the pymodbus lib: pip3 install pymodbus
• open a command line and execute the file python3 test.py

[LavermanJJ]

I'll upload a fixed version of the pysolarfocus lib as well as the hass-integration tonight. But I'm not sure if it'll fix the issue. As still with the current version, I don't get such error :upside_down_face:

[LavermanJJ]

with beta-5 this is what it looks like for me:

btw. I renamed it from "Pelletsboiler" to Biomass boiler, as this seems to be the generic term used by Solarfocus, to cover pellets, wood chips, and log wood. Do you agree?

[ragesoft]

I Tried it, but still no result and getting error 50003 on Solarfocus. "Biomass" seems to be correct so far ;)

Here is the readings with the help of WPF Modbus Examiner tool:

i can get the values. But not with the custom component. do i need to install something more? i only add the solarfocus add-on from hacs. And this is the components folder content:

[LavermanJJ]

Great that you were able to verify, that it works with the examiner tool 👍 The list of files within the custom component look good. Therefore, I guess the issue is in the way the pymodbus lib queries the data. As all the home-assistant mapping to names and converting values is transparent for the biomass boiler.

To localize the issue, it would be great if you could run the python script above and see if this works (please find the pymodbus client docs here and here). It seems like the biomass boiler is upset about the way we retrieve the data ... however, I have no clue why

[ragesoft]

if i run this script i get this error: /home # python3 test.py Traceback (most recent call last): File "/home/test.py", line 7, in <module> ).registers AttributeError: 'ExceptionResponse' object has no attribute 'registers'

with error output: Exception response(132, 4, IllegalValue)

:/

[LavermanJJ]

A more explanatory description of the exception can be found here: https://www.simplymodbus.ca/exceptions.htm

However, I'm confused whether the error number (4) or the name (illegal value) are correct ... I assume the latter.

Did play around with the count attribute? For example, to only read 1 register?

[ragesoft]

I allready tried this. no success at all... i also tried with other addresses, with and without "address=",...

from pymodbus.client.sync import ModbusTcpClient as ModbusClient

client =  ModbusClient(host="<my_solarfocus_ip>", port=502, log="info")
client.connect()

print(f"Connected: {client.is_socket_open()}")
# tested different settings...
#address=2400, count=1
#2400,1
#2400,count=1
req = client.read_input_registers(address=2400,count=1)
client.close()
print(f"Error: {req.isError()}")
print(req)
result_input = req.registers

print(f"Result: {result_input}")

[LLukas22]

@ragesoft Hello, I also tried to get this working with my Terminator II and encountered the same issue as above.

After some testing with pymodbus the problem seems to be the unitID passed to the client.read_input_registers() function.

In the pymodbus source the UnitID or SlaveID defaults to 0x00. For some reason the Therminator II can't work with IDs smaller than 1.

By forcing the unit to 1 i got a valide response from the server.

from pymodbus.client.sync import ModbusTcpClient as ModbusClient

HOST = "*"

client =  ModbusClient(HOST, port=502)
client.connect()

print(f"Connected: {client.is_socket_open()}")

response = client.read_input_registers(address=1901, count=1, unit=1)
if response.isError():
    print(f"Error!")
else:
    print(f"Success!")
    print(f"Value: {response.registers}")

client.close()

If this also works for you i could implement this into the pysolarfocus package.

[LavermanJJ]

Kudos that you found the issue! I can confirm that it also works with the unit=1 for the eco manager-touch. PR to the pysolarfocus would be great 👍 You could re-use the unit=SLAVE_ID also for the read_input and read_holding.

[ragesoft]

So great man!

/home # python3 test.py 
Connected: True
Error: False
ReadInputRegistersResponse (12)
Result: [726, 301, 0, 0, 0, 0, 43, 64537, 100, 0, 0, 0]

It works like a charm! :) @LLukas22 thx for this finding! @LavermanJJ im looking forward to see an update on the homeassistant plugin :) great work!!!

Also works for Heizkreis (start at 1100 count 7) and puffer (start at 1900, count 5) :)

👍

[LLukas22]

Alright i will probably create a PR tomorrow.

I will also add in some error handling and better logging via the default python logging library.

[LavermanJJ]

I've built a pre-release containing @LLukas22 changes: https://github.com/LavermanJJ/home-assistant-solarfocus/releases/tag/v1.2.0-beta-6 Feedback welcome!

[LavermanJJ]

😞 somehow doesn't work for me (no updates happening) ... will see tonight, if I can spend some time to debug.

Logger: root
Source: /usr/local/lib/python3.10/site-packages/pysolarfocus/__init__.py:618
First occurred: 13:52:53 (24 occurrences)
Last logged: 13:53:36

Connection to modbus is not established!

That check somehow does not work with the polling within home-assistant 🤔

[LLukas22]

Im getting the same Error in my log

2022-10-02 14:38:10.004 ERROR (SyncWorker_2) [root] Connection to modbus is not established!
2022-10-02 14:38:10.004 ERROR (SyncWorker_2) [root] Connection to modbus is not established!
2022-10-02 14:38:10.005 ERROR (SyncWorker_2) [root] Connection to modbus is not established!
2022-10-02 14:38:10.005 ERROR (SyncWorker_2) [root] Connection to modbus is not established!
2022-10-02 14:38:10.005 ERROR (SyncWorker_2) [root] Connection to modbus is not established!
2022-10-02 14:38:10.006 ERROR (SyncWorker_2) [root] Connection to modbus is not established!
2022-10-02 14:38:10.006 ERROR (SyncWorker_2) [root] Connection to modbus is not established!
2022-10-02 14:38:10.006 ERROR (SyncWorker_6) [root] Connection to modbus is not established!
2022-10-02 14:38:10.006 ERROR (SyncWorker_8) [root] Connection to modbus is not established!
2022-10-02 14:38:10.006 ERROR (SyncWorker_8) [root] Connection to modbus is not established!
2022-10-02 14:38:10.006 ERROR (SyncWorker_8) [root] Connection to modbus is not established!
2022-10-02 14:38:10.006 ERROR (SyncWorker_8) [root] Connection to modbus is not established!
2022-10-02 14:38:10.007 ERROR (SyncWorker_8) [root] Connection to modbus is not established!
2022-10-02 14:38:10.007 ERROR (SyncWorker_3) [root] Connection to modbus is not established!
2022-10-02 14:38:10.007 ERROR (SyncWorker_3) [root] Connection to modbus is not established!
2022-10-02 14:38:10.007 ERROR (SyncWorker_3) [root] Connection to modbus is not established!
2022-10-02 14:38:10.007 ERROR (SyncWorker_3) [root] Connection to modbus is not established!
2022-10-02 14:38:10.007 ERROR (SyncWorker_0) [root] Connection to modbus is not established!

The problem seems to be that the modbus connect methode is never called. Looking into the init.py the modbus_client is created but never connected to the server. I also couldn't find any other function that would connect it to the server. I guess the error message is correct because we actually aren't connected to the server.

[LavermanJJ]

Good catch! 👍 I've added it to the SolarfocusDataUpdateCoordinator as the coordinator handles the retrieval of the data via the lib. and provided a new release

[LLukas22]

Just updated, the connection is working now 👍

The values also seem to be valid, exept for the boiler ash container (maybe the sensor is blocked or dirty). Im gonna take another look tomorrow.

@ragesoft Would be great if you could also validate that the data retrieval is working for you.

[ragesoft]

@LLukas22 Same here. Looks a little strange. But I get data now!

@LavermanJJ Is it possible to subsequently change the extensions for heating circuit and buffer on the integration?

[ragesoft]

btw: https://github.com/LavermanJJ/home-assistant-solarfocus/blob/5a9c0f4878531223f48a85ecce520497ea79d398/custom_components/solarfocus/strings.sensor.json#L203

There is a typo. Status 301 missing because of none closing ' " ' and new line :)

[LavermanJJ]

Typo is fixed.

What changes for heating circuit and buffer are you referring to? Are the register numbers different? Or are you referring to the state messages (offset +200)? The latter should be present and the former #worksOnMyMachine 🤣 ... no seriously, if there is something with the registers, that would mean eco manager-touch and terminator are incompatible, i guess 🤔

[ragesoft]

I mean, if i initial add the solarfocus intigration, i got this options, but i first only selected boiler. Now i want to extend my integration with the other options. only change right now is to delete current integration and add it back with new settings (i guess) :)

[LavermanJJ]

That's right 🙈 ... that would need the option flow. However, so far I couldn't get it to work. Therefore, the remove and re-add is the only option for the moment. But as the entities are named the same, the history won't be lost 👍

[ragesoft]

nice. i see. :)

One last issue (i hope) with this integration for the therminator:

it seems some readings are not correct? What does the "heating state" shows? in my setting it toggles quite often... but this numbers are no known status numbers... (maybe there is some miss-match in mapping to the "heating mixer value"??) "buffer mode" is a number instead of text

values for "Solarfocus Heating supply temperature" seems to be correct. :)

[LavermanJJ]

Buffer mode should be buffer state, therefore the number to text mapping isn't working.

Seems that there are a few things twisted 😟 Could you upload a screenshot of your modbus analyzer of buffer and heating registers to ease debugging?

[ragesoft]

heating circuit 1 and buffer 1:

[LavermanJJ]

Thanks for providing the screenshots. I've attached the same from my system. As you can see the issue is with the "missing" /empty registers on my system. As the pysolarfocus lib is currently working with offsets, that doesn't work. Therefore, the two implementations (Therminator, Vampir) aren't compatible. We'd need to

1. take a deeper look into the pymodbus lib, or
2. Adapt the implementation of pysolarfocus to either
   1. Use two different register definitions to continue the support of range requests
   2. Switch from range requests to query distinct addresses
3. Check with Solarfocus, why they have different implementations

[LLukas22]

In my oppinion the best option we have is to change the pysolarfocus library to work with distinct addresses. I dont think pymodbus has a feature that would allow us to dynamically parse/request addresses. Solarfocus probably wont change their modbus implementation, there are already system build depending on the existing address layout.

Changes i would recomend for the pysolarfocus library:

1. We could implement an enum that defines if we connect to a Terminator or a Vampir system and pass it to the constructor (In homeassistant that could be a dropdown while adding the integration)
2. All address ranges shared between the systems dont need to be changed. Depending on the passed enum specific addresses definitions are loaded
3. Every address definition should be changed to have the following values:
   • Address
   • Range (Read 1 or multiple registers)
   • Type (Int/UInt etc.)
   • Name/Key (A unique Key to assign a mapper for this value)

[LavermanJJ]

Sounds like a plan 👍 I did not do any performance testing, but I assume the range requests being less overhead and hence faster and "cheaper". Therefore, if we anyway have to differentiate between the two systems, why not provide two definitions and support ranges for both?

While I agree, that Solarfocus will most likely not adapt it, I guess it will nevertheless make sense to make them aware.

Regarding implementation:

• I will provide Modbus Examiner screenshots of the VampAir registers, to identify which registers are affected.
• @ragesoft can you confirm (via Modbus Examiner), that for Therminator the register values fit 100% to the spec?
• I could adapt the integration config-flow to provide the selection ... maybe I have a run and fix the option-flow as well 😄
• @LLukas22 would you want to give the pysolarfocus changes a try and provide a PR for that?
  • What about the multiplier information? Would that also be locate in the address definition? (or maybe I did not yet fully understand your idea)

[LLukas22]

Regarding the performance of range reads compared to multiple single address reads you are probably right.

I will have another look at the implementation after work, i wanted to abstract the single components of the system into objects. These objects will define the address range and a parse function. To implement the different Solarfocus devices we only have to verwrite these component objects, define the range and overwrite the parse function.

I will porbably try to implement this for the existing VampAir implementation first, then i can evaluate if we actually need it or if we should stick with the dictionary definitions.

[LLukas22]

@LavermanJJ I created a new issue in the pysolarfocus repo regarding my propsed changes. Would be great if you could take a look.

[ragesoft]

Yesterday my Integration stoped updating the values. A Quick check on termi Shows error 32601. There where more then 260.000 query until this point. The "Master" counter Shows "5" => maybe there is some problem with the latets update? It reconnects to often? It dont close connection correct? I Updates to Main 1 or 2 days before this error. Only reboot has solved the error (until now) Also i want to change the pull intervall, how can i achiv this? Only through delete and recreate?

[LavermanJJ]

I'm still struggling with the "options" flow, so for now delete and re-create is the only way unfortunately.

Regarding the reconnects: I haven't experienced this myself so far. Might be what you assume, not sure.

[LLukas22]

@ragesoft I can't test this right now, but it's a possibility that the querry counter overflows or some stuff like that. (I've read throught some of their documentation and it's not really helpfull) The connection should probably be "self-healing", meaning that we automatically diconnect and reconnect when we don't get valid data from the server. This is probably a seperate issue with no connection to the Therminator compatability. You should probably create a new issue for this.

[LavermanJJ]

I've merged #14 - please let me know, if (after re-adding the integration) things are working with the Therminator.