Testing with Solis Inverter

[gedger]

If you would prefer any of these raised as issues then please let me know.

I realise the integration is undergoing a lot of changes at the moment but I think there needs to be some regular (daily?) beta releases. I've installed via HACS and hence have version 24.07.14 and there are several items not working 100%, for example the update_interval doesn't work? I suspect these items have already been fixed but as there are no other later releases it's hard to raise an issue against a specific version. Hence I haven't raised any issues yet....

I found it odd to have to specify battery parameters on the configuration page when my inverter has no battery. Wouldn't these items be better in the configuration file for each inverter?

Several of my template sensors failed as they were being triggered by a last_update_sensor provided by the StephenJoubert integration but not yours. As many people will be moving from that integration it may be useful to add a migration help page which we can add these type of observations to?

On the big plus side the integration is a huge improvement over the StephenJoubert variant so a huge thanks for taking this on.

[davidrapan]

Hi! Thanks for your post!

I set the release cycle for 04., 14. and 24. every month and also the versioning will match those so it's clear. When comes to dev versions I try to always keep the current main in a "working" state but there is no guarantee sure. I was thinking maybe some nightly dev cycle but I still did not put much thought into it yet!

Currently if you are on the 24.07.14 and did not download code manually you can refer that version with no problems.

When comes to the configuration yes the Battery Settings and some others are still a subject to change and I will use OptionsFlow for it in the future.

Last Updated value is part of the Connection sensor and you can read it like this:

states.sensor.inverter_connection_state.last_updated | as_local

I have planned in near future to also extend this diagnostic part from the integration rather than using 'configuration.yaml' separatedly. But I'm still learning about the HA so it's a journey, haha. 😉

Could you maybe show how did you used the sensor? So I can better help you with the migration? But I'm sure that with Stephan's integration there was really need for that because of the stability issues and it really should not be a problem here. You should always have the most recent and correct values and if that's not the case there is something wrong and should be fixed rather than patched with some detection mechanics.

[gedger]

I'm using the solis_1p8k-5g.yaml configuration which I created and pushed into Stephans integration so I could well be the only person using it 😄

[davidrapan]

I see there is a PV Power both only as a Total? And you also want each separatedly? You sure there are no registers for it, right?

"float+0.1" does this what i think it does? 😆

[davidrapan]

This could be placed in your profile:

- name: PV1 Power
  class: "power"
  state_class: "measurement"
  uom: "kW"
  rule: 1
  digits: 3
  registers: [3021, 3022]
  sensors:
    - registers: [3021]
      scale: 0.1
    - operator: multiply
      scale: 0.001
      registers: [3022]

But after today's commit, I still had to add multiply and divide operators.

But still don't know about that +0.1. 😆

[gedger]

Excellent, thank you. The 0.1 was a fiddle factor to try and calibrate the result but it can be removed. There was no register I could find that gave the individual string power output....

I also calculate inverter efficiency. The ([0, eff, 99]|sort)[1] was to ensure the value was always between 0-99 as I did get the occasional bonkers value....

- trigger:
  - platform: state
    entity_id:
      - sensor.solis_status_lastupdate
  sensor:
  - name: Solis Inverter Efficiency
    unit_of_measurement: '%'
    state_class: measurement
    state: >-
      {% set ac_power = states('sensor.solis_inverter_ac_power')|float(0) %}
      {% set dc_power = states('sensor.solis_total_dc_power')|float(0) %}
      {% if ac_power and dc_power %}
      {% set eff = (ac_power / dc_power * 100)|round(1) %}
      {{ ([0, eff, 99]|sort)[1] }}
      {% else %}
        0
      {% endif %}

[davidrapan]

- name: Inverter Efficiency
  class: ""
  state_class: measurement
  uom: "%"
  rule: 1
  digits: 1
  uint: enforce
  registers: [3005, 3004, 3007, 3006]
  sensors:
    - signed:
      registers: [3005, 3004]
    - operator: divide
      signed:
      scale: 100
      registers: [3007, 3006]
  validation:
    min: 0
    max: 99

[gedger]

For some reason I can't get the inverter efficiency working....but the PV power works fine. I'll keep investigating...

Some other sensors that used the scale_division option have also stopped working, will these need converting to use the new operator syntax?

    - name: "WStatus Derating"
      class: ""
      state_class: ""
      uom: ""
      scale_division: 32
      rule: 1
      mask: 0x20
      registers: [3071]
      icon: 'mdi:list-status'

[davidrapan]

'scale_division' was something i noticed as latest features of Stephans integration. But that was after I was working on mine. What's it supposed to do anyway?

And what do you mean by not working? What it shows?

First thing what comes to my mind try to double check if there is correct order of low 16 bits and high 16 bits.

[gedger]

It divides the answer by a value, in my case 32 and is useful for bit fields. In the example it first masks the bitfield to select bit 6 (mask: 0x20) then shifts right (scale_div: 32) to create an 1 or 0 if bit 6 is active.

[davidrapan]

Ah sure, makes sense. I didn't need it yet so... But I can add it. ;)

[davidrapan]

a677eb3

I put it there so let me know when you'll have the chance to test it as I'm unsure if i picked the correct pos where to do the operations. 😉

[davidrapan]

I found an use-case for it so I tried it and it looks like it works! f359b59

[gedger]

Solved the inverter efficiency, by changing where the scaling is done? So

      sensors:
        - registers: [3005, 3004]
          signed:
        - operator: divide
          signed:
          scale: 100
          registers: [3007, 3006]

becomes

      sensors:
        - registers: [3005, 3004]
          signed:
          scale: 100
       - operator: divide
          signed:
          registers: [3007, 3006]

and it all works?

[davidrapan]

Ha! Interesting... But I'm glad it has a solution!

[davidrapan]

Don't you want to make changes into that profile file according the one you are using and make a PR?

[gedger]

I will once I have sorted an alternative for the missing scale_divide...

[davidrapan]

It's already there!

Changes
Where I already used it

[gedger]

Yup, I just needed to make the changes. Now done and attached, sorry I still need to master Git....One question, I have presumed that the order of precedence takes priority over the order the items appear in the configuration file?

solis_1p8k-5g.yaml.zip

[davidrapan]

What order you mean exactly? Of sensors???

[gedger]

Is

 mask: 0x40
 divide: 64

the same as

divide: 64
mask: 0x40

I.e. does normal mathematical precedence apply so mask, then plus/minus then multi/divide

[davidrapan]

Yes mask goes always first, it does not look at their position.

[davidrapan]

You commented out in your profile Total Generation, is that right?

[gedger]

It's up to the user, I don't find those parameters of any use so I don't collect the data but I found the registers so put them in the profile. That's why I use the custom_configuration.yaml so I can only collect the data I need which is preserved during upgrades and in case someone else adds some sensors into the profile....

[davidrapan]

There is a better approach how to do it. And that is to disable the sensor inside HA. ;) That will also survive the updates and many more. ;)

[davidrapan]

But still are you sure you don't need that sensor? You are not using energy dashboard? You should use in that dashboard total not today or daily sensor ;) Sensor which resets on its own can introduce miscalculations into energy calcualtions... cause of time synchronizations, etc.

[gedger]

I have a Tesla Powerwall that provides the same information and it's much more accurate than the Solis inverter.

If you disable the sensor in HA does the integration still get the data from the inverter or does it remove it from the request? I think I removed them from the configuration as the SJ integration used to regularly have connection issues and minimising the amount of data you requested seemed to improve reliability...but that's not the case now...

[davidrapan]

Yes exactly I made this integration cause of the connection issues. So that's no longer the case here. I'm trying to optimize number of requests and so as much as possible. And there still are some places where I can improve on that and one of them is to propagate that disabled state from HA. In case of your profile I'm sending always single request so you should not see any difference.