Overview of Addresses and Home Assistant discovery snippets

[EarlSneedSinclair]

Thank you for this great project!

I would love to contribute by sharing my verified data points and also contributing snippets for the Home Assistant discovery. From my point of view, it would be helpful to create a table with the poll_items for the settings_ini and the JSON item for Home Assistant. This way, it would be a simple copy & paste for everyone. Unfortunately, this list here is quite hard to read, and there might be better solutions for GitHub: https://github.com/openv/openv/wiki/Adressen

Example entry for the Water storage temperature

Device

CU401B-S

settings_ini

("water_storage_temp", 0x010B, 2, 0.1, False),  # WPR_HeizwasserPufferspeicher_Temperatur

JSON

{
    "domain": "sensor",
    "name": "Water storage temp",
    "unit_of_measurement": "°C",
    "icon": "mdi:thermometer-lines"
},

Please let me know what you think about this, and feel free to create a template if possible.

[FransOv]

It will sadly never be a simple copy/paste. The heatpumps differ to much in what parameters are relevant for each type. The example I made in the wiki for the 300-G (https://github.com/philippoo66/optolink-splitter/wiki/210-Home-Assistant-Integration-of-Optolink%E2%80%90Splitter) has been adapted by several other users. I might be an idea to invite all users of Optolink-Splitter to share their polling list and, if they are using Homeassistant their discovery json.
I found the list of addresses in the wiki of the openv project far less complete than the, admittedly hard to read, Excel file from the Vitosoft database.

[EarlSneedSinclair]

Yes, I agree that "copy/paste" sets expectations too high. It would be more accurate to talk about providing additional examples or sharing files, as you suggested.

I did the same and tried to adapt the given example from the wiki to the Excel file. As you mentioned, it’s hard to read and challenging for someone who isn’t a developer. That’s why I also thought about sharing such files.

Creating a table was just an idea, but sharing files could also be a way to support beginners and non-professionals. The structure and format should be easy to access. Since the Excel file needs to be downloaded and uploaded again, it’s not ideal. However, regardless of the file format, it could be extended with columns for the settings.ini and JSON snippets, as well as a column for "confirmed working", where devices can be added.

Another idea I could imagine is creating wiki pages to share complete files in a tree structure organized by device (e.g., CU401B-S).

[philippoo66]

hi @EarlSneedSinclair !

Unfortunatley I do not not know nothing of how Home Assistant works so I can't contribute anything. But I realized you already found your way to the Wiki. It looks good to me, so please continue developing ideas and realize them!

According to my very poor understanding - might it be a way to create a Wiki page e.g. "220 Home Assistant Files bla bla" with captions describing the decive and below each caption have two files a) the json shown on your 210 page and b) the according poll_list?

The json to get processed by your given script, and perhaps in the splitter we separate the poll_list from settings_ini so that poll_list.py just need to get copied?

(edit: probably this is what you had in mind writing "creating wiki pages to share complete files in a tree structure organized by device"...)

anyway - thank you very much for your support and cocreation!! go on!

kind greetings!
Phil

[FransOv]

That could work. It will need some preparation though. You cannot open up the wiki pages for everyone. At some time this is bound to attract abuse when it becomes wider known. @philippoo66 the wiki has been open to editing for some time now, what is your experience with this?

[philippoo66]

no abuse at all up to now, only constructive adds.

in case something bad would happen, it is allways possible to get the previous state back (and close the open write access) or am I wrong? unfortunately I did not find a way to require changes to be 'reviewed' somehow - I think there isn't? only fully open or closed....

[FransOv]

There is some info on moderating discussions https://github.com/github/docs/blob/main/content/discussions/managing-discussions-for-your-community/moderating-discussions.md
you could have the submissions initially via discussions and have a moderator transfer them to the wiki.

[philippoo66]

hm I got confused because looking at the history of 210, I only saw 3 revisions made by @EarlSneedSinclair . Sorry @FransOv , obviously it was you who created it. Why don't I get the complete History??

ok, the workaround looks promising on the first look, I will take another look tomorrow, now it's quite late...

but in general we will follow that "creating wiki pages to share complete files in a tree structure organized by device" idea?! (even if managed anyway, we might also create a folder/structure in the project?!)

perhaps we should also add the script and a json fitting the poll_list to the project 'as a sample'?!

[philippoo66]

@FransOv does the json in 210 fit the poll_list? should we add the create_entities script and the json to the project folder and separate poll_list from settings_ini?

[FransOv]

I don't think separating the settings_ini.py and the poll_list will bring many advantages. Including the create_entities script and the json in the project files will help new users. I'll have to bring the script a bit up to standards however. At least with a proper open file for the json, not just assuming it will be called vitocal.json.

[philippoo66]

name it vito.json. don't we intend to build up a 'library' for those files?! in that case a common name would make sense. Keep it simple... ;-)

[philippoo66]

the intent to separate poll_list is according to that - the user simply need to pick the poll_list.py from the library. no need to edit files on a unix system... ?!

[FransOv]

I'm afraid creating a pull request is somewhat above the skill set of a casual user. I'd prefer a pinned discussion with a top item inviting viewers to share their polling lists, their way of integrating with Home Automation systems and other suggestions for the wiki. It would then be up to the collaborators to promote a contribution to the wiki. Only collaborators then need write access to the wiki. In this way it would also be possible to maintain a sort of house style for the wiki.

[philippoo66]

as far as I know even the openV Wiki is open (at least I can edit it and I don't think I'm a 'registered co-worker' or so). If somebody does bullshit, he can get identified without problems, so I think it is quite 'safe'?!

[FransOv]

Yes, the json and the poll list fit together. They are both a bit outdated however. I can prepare a new wiki page with the current poll list, the json and a screenshot of how it looks in Home Assistant.
Let's try to set it up as you suggested earlier: open wiki and make it secure
when abuse becomes problematic.
Ways to be notified of a wiki change: https://stackoverflow.com/questions/8407917/how-can-you-track-or-be-notified-of-changes-to-github-wikis

[philippoo66]

hi @FransOv !

I'm looking for a tree-structure for the collection page https://github.com/philippoo66/optolink-splitter/wiki/350-Poll-Configuration-Samples

With heatpumps I'm not sure how best to structure - 200/300 or S/A/G or ... (I don't know nothing regarding heat pumps ;-) )

could you please edit the page to raise a tree!? and perhaps already add the first sample/s (yours)?!

I think with the splitter I will implement something like

if(file.exists('poll_list.py'):
    import poll_list
    pollitems = poll_list.poll_items
else:
    pollitems = settings_ini.poll_items

This way we could use poll_list.py's directly copied from the Wiki page and stay downward compatible.

The create_entities.py script we should add to the project, always using file entities.json

What do you think?!

[FransOv]

Hi Phil, I’ll make the changes, but it will be the middle of next week before I can find time. I did shift a deadline from this week to the next as I had to integrate a new inverter. Installed an SMA Home Storage Battery that needed a hybrid inverter and that hybrid inverter did not present the PV Yield via ModBus. So a change that should have been simple turned out to have more consequences than foreseen. Learned a lot though, but I now need to work on that deadline (that is not even interesting work). The way you propose the change to the poll_list file is nice, will not break existing installations. I’ll change the create_entities script and put in in the code section. Changing the script to a file dialog is no great effort, but it needs installation of an additional package that is not readily available on older Python versions. So let’s keep it simple with the fixed filename. Regards, Frans From: Phil ***@***.***> Sent: vrijdag 10 januari 2025 14:46 To: philippoo66/optolink-splitter ***@***.***> Cc: FransOv ***@***.***>; Mention ***@***.***> Subject: Re: [philippoo66/optolink-splitter] Overview of Addresses and Home Assistant discovery snippets (Discussion #65) hi @FransOv <https://github.com/FransOv> ! I'm looking for a tree-structure for the collection page With heatpumps I'm not sure how best to structure - 200/300 or S/A/G or ... (I don't know nothing regarding heat pumps ;-) ) could you please edit the page to raise a tree!? and perhaps already add the first sammple/s (yours)?! I think with the splitter I will implement something like if(file.exists('poll_list.py'): polldata = poll_list.poll_list else: polldata = settings_ini.poll_list This way we could use poll_list.py's directly copied from the Wiki page. The create_entities.py script we should add to the project, always using file entities.json What do you think?! — Reply to this email directly, view it on GitHub <#65 (reply in thread)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AN2P65YW7ZA3MOSZEGFCAOL2J7FHZAVCNFSM6AAAAABUIUQCSOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNZZHAZTMMY> . You are receiving this because you were mentioned. <https://github.com/notifications/beacon/AN2P6557G4PPNOHQHYXNZUT2J7FHZA5CNFSM6AAAAABUIUQCSOWGG33NNVSW45C7OR4XAZNRIRUXGY3VONZWS33OINXW23LFNZ2KUY3PNVWWK3TUL5UWJTQAWQDVW.gif> Message ID: ***@***.*** ***@***.***> >

[FransOv]

I see what you mean, but never felt the need to delve in the mqtt messages myself. With 60+ devices jabbering to the mqtt broker (mosquitto) it is more than a mere human can cope with, I just make sure that all clients have an unique main topic.
If you feel that the node-id is needed, feel free to add support for it. Maybe make it optional, if the node is null skip that level in the mqtt message.

[philippoo66]

öhm, I can't follow (I do not understand)... does Home Assistant post the MQTT stuff 'back' to the broker??

originally, by the splitter, all the topics (datapoints) get posted under what is given as mqtt_topic = ... in setting_ini?!?

[philippoo66]

if a further level is required, it could be mqtt_topic = "sensor/UG_Heizung_WP".

Also the datapoints can get 'grouped' using

    ("hk1/requested_temperature", 0xA406, 2, 0.01, False),
    ("hk1/normal_temperature", 0x2000, 2, 0.1, False),
    ("hk2/requested_temperature", 0xA446, 2, 0.01, False),
    ("hk2/normal_temperature", 0x3000, 2, 0.1, False),

every / causes an additional 'level'

[FransOv]

The discovery messages just tell HA which entities to create and to subscribe to which mqtt topics, sent by the splitter, for the values. Thereafter you just work with the entities in HA and you don't need to see the mqtt messages anymore.

[FransOv]

This is part of the unsorted list of entities created.

And this part of the dashboard is created using the Vitocal entitles and entities of other sources.

[lellem]

Hello together,

i'm using HA for about 1 year to control a Vitocal 200-16.A, PV with storage, room temperature and so on...
Until now i'm using the Viessmann ViCare Integration, but now i'm testing the optolink-splitter. I think i can share my settings, vito.json, and so on soon.

It's realy hard to find out all the addresses, e.g. to see if dwh active, compressor running, one shot dhw, etc...

[philippoo66]

great, thank you, too!

As I said, the idea is to collect tested an working configurations. But just starting to develop a concept, the first disadvantage shows up: How to find the implementation of a certain data point? Attached files aren't online searchable... Do you have an idea?!

[philippoo66]

another aspect: pure settings often do not make sense to integrate in poll_list but are not less important to share...

[FransOv]

I finally found the datapoint for the mixer valve of the divicon on HK2, the third byte of an 8 byte value at 0x0600, 0 to 100%:
("hk2_mixer_valve", 0x0600, 8, 'b:2:2', 1, False),
It's not a measured value obtained from the valve, but a computed value based on the duration of open/close commands from the controller.

[philippoo66]

@FransOv do you think we can 'take the risk' do merge develop into main now?! I think the latest merges to main (the HA entities stuff) should cause no conflicts?

[FransOv]

The HA entities functions are completely seperate so no conflicts possible and you can merge whenever you want to /need to.
There is one change that I see as of value: Create the file poll_list.py with the polling items and empty the poll_list array in settings_ini.py.
I have not tested the pollCycle feature. Frankly I don't see much added value in it. The saving in network traffic are minimal. The refresh times for the remaining poll items will be slightly better, but the timings are not critical. I can test it if you want, but it will likely be a less rigorous test than you already did, due to the fact that you have a much better knowledge of how things should work.

[philippoo66]

Frankly I don't see much added value in it.

I agree. I applied (and reworked) it since Kristian did some work for it and raised a pull request and there was another similar request by lellem. I think reducing the olbreath time is more usefull and with this also the refresh intervall stays constant.

You don't need to invest time for testing. If there will be something I did not see, then it will get reporten if the feature will get utilized...

Ok, I think I will raise the develop to main now soon. I think we can leave the poll_items list in settings_ini as it is, since it is a good and template and simple way to start. Utilizing the poll_list.py's of Wiki page 350 is easy simply by copying the file into work dir and settings_ini don't need to get touched for that.

[EarlSneedSinclair]

@philippoo66, I briefly tested the PollCycle on a couple of data points and can confirm that it works, at least for me. I also experimented with the olbreath, setting it to 0.05, and observed no negative impact on the VitoConnect Opto2/ViCare app.

/Edit:
I've just updated the wiki article to reflect the changes made to the Home Assistant entities files.

[philippoo66]

great, thank you! :-)

[FransOv]

Today also found the Error codes of the Vitocal heatpumps in case of an error situation. It is a 256 bitstring (32 bytes) at 0x0700. The hex position of a one bit in the bitstring (zero-based) is the diagnostic message code.
Below the code for a HA template sensor to extract the error message numbers (there can be more than one) from the bitstring. vitocal_errormsg is the hex representation of the bitstring:

{% set bits=states("sensor.vitocal_errormsg")|list %}
{% set ns=namespace(errors="") %}
{% set ns.pos=[[8,1],[4,2],[2,3],[1,4]] %}
{% for bit in bits %}
  {% if bit!="0" %}
    {% set q=bit|int(base=16) %}
    {% set bx=loop.index*4 %}
    {% for px in ns.pos %}
      {% if q|bitwise_and(px[0])!=0 %}
        {% set ns.errors=ns.errors~'{:X}'.format(bx+px[1])~" " %}
      {% endif %}
    {%  endfor %}
  {% endif %}
{% endfor %}
{{ ns.errors }}

[EarlSneedSinclair]

Wow, another large step towards switching completely to local / getting rid of ViCare.

Since I don't have an issue right now, I can't verify if it's working. Is my setup correct?

poll_list
("errormsg", 0x0700, 32),

homeassistant_entities.json
{"domain": "sensor", "name": "errormsg", "unit_of_measurement": "", "state_class": "measurement", "icon": "mdi:alert-circle"},

A template sensor in Home Assistant, as you mentioned in your previous post. Or did you find a way to include that in homeassistant_entities.json, given that MQTT discovery supports value templates, which we discussed for my eHeating switch or which you use in the climate entities (link)?

{% set bits=states("sensor.vitocal_errormsg")|list %}
{% set ns=namespace(errors="") %}
{% set ns.pos=[[8,1],[4,2],[2,3],[1,4]] %}
{% for bit in bits %}
  {% if bit!="0" %}
    {% set q=bit|int(base=16) %}
    {% set bx=loop.index*4 %}
    {% for px in ns.pos %}
      {% if q|bitwise_and(px[0])!=0 %}
        {% set ns.errors=ns.errors~'{:X}'.format(bx+px[1])~" " %}
      {% endif %}
    {%  endfor %}
  {% endif %}
{% endfor %}
{{ ns.errors }}

[FransOv]

Looks OK. If you have a Vitotrol thermostat you can force an error (Loss of communication from a KM bus member: EE) by disconnecting it. I have not tried to create a template sensor via the vitocal.json. Should be possuble, but a template helper was easier.
I have one issue though, I get an error 81 exactly one hour after the compressor starts at 100%. It is a sort of phantom error associated with the Natural Colling Box, has no effect heatpump just keeps working. The error shows up on the heatpump display, but not in the app. However it does not seem to set the correct bit in the bitstring, not on 0x81 but on 0x8B.