Migrating over from StealthChesnut integration (finally) - how to avoid duplicate sensors? #342

calum-mcfarlane · 2023-06-23T10:49:29Z

calum-mcfarlane
Jun 23, 2023

Finally got around to trying to migrate to this integration, following Dave Foster's directions here.

I removed the modbus: !include custom_components/foxess/modbus485.yaml line from my configuration.yaml, as well as the other custom template sensors defined there (see Sensors Removed, below).

I left in the utility_meter section, as well as all the integration sensors (each included in their own sections)

Once I'd done this I restarted HA, confirmed that the dashboards were all showing "Not available" and then installed foxess_modbus from HACS.

The install went fine, but after restarting I found that I had duplicate sensors all over the show with the dreaded "_2" appended.

I'd taken a full image back of my HA VM before I started so I've gone back to that for now, but I'm wondering what I did wrong in my process - do I need to delete the old entities somehow before installing the integration from HACS?

Sensors Removed

- name: "Battery Discharge"
      unique_id: foxess_inv1_battery_discharge
      device_class: "power"
      unit_of_measurement: "kW"
      state: >
          {% if (states('sensor.battery_discharge_power') | float(default=0) ) > 0 %}
          {{ states('sensor.battery_discharge_power') | float(default=0) * 1 }}
          {% else %}
          0 
          {% endif %}
    - name: "Battery Charge"
      unique_id: foxess_inv1_battery_charge
      device_class: "power"
      unit_of_measurement: "kW"
      state: >
          {% if (states('sensor.battery_discharge_power') | float(default=0) ) < 0 %}
          {{ states('sensor.battery_discharge_power') | float(default=0) * -1 }}
          {% else %}
          0 
          {% endif %}

    - name: "Grid Consumption"
      unique_id: foxess_inv1_grid_consumption
      device_class: "power"
      unit_of_measurement: "kW"
      state: >
          {% if (states('sensor.grid_ct') | float(default=0) ) < 0 %}
          {{ states('sensor.grid_ct') | float(default=0) * -1 }}
          {% else %}
          0 
          {% endif %}
    - name: "PV Power Now"
      unique_id: foxess_inv1_pv_power_now
      device_class: "power"
      unit_of_measurement: "kW"
      state: >
            {{ (states('sensor.pv1_power') | float(default=0) + states('sensor.pv2_power') | float(default=0) ) * 1 }}
    - name: "PV Energy Daily"
      unique_id: foxess_inv1_pv_energy_daily
      device_class: "energy"
      unit_of_measurement: "kWh"
      state: >
            {{ ((states('sensor.pv1_daily') | float(default=0) + states('sensor.pv2_daily') | float(default=0) ) * 1 ) | round(2) }} 
    - name: "System Losses"
      unique_id: foxess_inv1_system_losses
      device_class: "power"
      unit_of_measurement: "kW"
      state: >
             {{ ((states('sensor.pv1_power') | float(default=0)
             + states('sensor.pv2_power') | float(default=0)
             + states('sensor.grid_consumption') | float(default=0)
             + states('sensor.battery_discharge') | float(default=0)
             - states('sensor.battery_charge') | float(default=0)
             - states('sensor.feed_in_power') | float(default=0)
             - states('sensor.load_power') | float(default=0) )) | round(2) }}
    - name: "Time Period 1 - Start Time"
      unique_id: foxess_inv1_time_period_1_start_time
      icon: "mdi:calendar-clock"
      state: >
        {% set raw_time = states('sensor.time_period_1_start') | int %}
        {% set hours = raw_time // 256 %}
        {% set minutes = raw_time - (hours * 256) %}
        {{ strptime(hours | string + ":" + minutes | string, '%H:%M').time() }}
    - name: "Time Period 1 - End Time"
      unique_id: foxess_inv1_time_period_1_end_time
      icon: "mdi:calendar-clock"
      state: >
        {% set raw_time = states('sensor.time_period_1_end') | int %}
        {% set hours = raw_time // 256 %}
        {% set minutes = raw_time - (hours * 256) %}
        {{ strptime(hours | string + ":" + minutes | string, '%H:%M').time() }}
    - name: "Time Period 2 - Start Time"
      unique_id: foxess_inv1_time_period_2_start_time
      icon: "mdi:calendar-clock"
      state: >
        {% set raw_time = states('sensor.time_period_2_start') | int %}
        {% set hours = raw_time // 256 %}
        {% set minutes = raw_time - (hours * 256) %}
        {{ strptime(hours | string + ":" + minutes | string, '%H:%M').time() }}
    - name: "Time Period 2 - End Time"
      unique_id: foxess_inv1_time_period_2_end_time
      icon: "mdi:calendar-clock"
      state: >
        {% set raw_time = states('sensor.time_period_2_end') | int %}
        {% set hours = raw_time // 256 %}
        {% set minutes = raw_time - (hours * 256) %}
        {{ strptime(hours | string + ":" + minutes | string, '%H:%M').time() }}

Utility Meters (kept)

utility_meter:
  load_daily:
    unique_id: foxess_inv1_load_daily
    source: sensor.load_sum
    cycle: daily
  pv1_daily:
    unique_id: foxess_inv1_pv1_daily
    source: sensor.pv1_sum
    cycle: daily
  pv2_daily:
    unique_id: foxess_inv1_pv2_daily
    source: sensor.pv2_sum
    cycle: daily
  bat_charge_daily:
    unique_id: foxess_inv1_bat_charge_daily
    source: sensor.bat_charge_sum
    cycle: daily
  bat_discharge_daily:
    unique_id: foxess_inv1_bat_discharge_daily
    source: sensor.bat_discharge_sum
    cycle: daily
  feedin_daily:
    unique_id: foxess_inv1_feedin_daily
    source: sensor.feedin_sum
    cycle: daily
  grid_daily:
    unique_id: foxess_inv1_grid_daily
    source: sensor.grid_consumption_sum
    cycle: daily
  losses_daily:
    unique_id: foxess_inv1_losses_daily
    source: sensor.losses_sum
    cycle: daily

Integration sensors (kept)

#Sensors turn power values into power/hour values for meters
sensor: 
  - method: left
    name: pv1_sum
    unique_id: foxess_inv1_pv1_sum
    platform: integration
    round: 2
    source: sensor.pv1_power
    unit_time: h
  - method: left
    name: pv2_sum
    unique_id: foxess_inv1_pv2_sum
    platform: integration
    round: 2
    source: sensor.pv2_power
    unit_time: h
  - method: left
    name: pv_total_sum
    unique_id: foxess_inv1_pv_total_sum
    platform: integration
    round: 2
    source: sensor.pv_power_now
    unit_time: h
  - method: left
    name: load_sum
    unique_id: foxess_inv1_load_sum
    platform: integration
    round: 2
    source: sensor.load_power
    unit_time: h
  - method: left
    name: bat_charge_sum
    unique_id: foxess_inv1_bat_charge_sum
    platform: integration
    round: 2
    source: sensor.battery_charge
    unit_time: h
  - method: left
    name: bat_discharge_sum
    unique_id: foxess_inv1_bat_discharge_sum
    platform: integration
    round: 2
    source: sensor.battery_discharge
    unit_time: h
  - method: left
    name: feedin_sum
    unique_id: foxess_inv1_feedin_sum
    platform: integration
    round: 2
    source: sensor.feed_in_power
    unit_time: h
  - method: left
    name: grid_consumption_sum
    unique_id: foxess_inv1_grid_consumption_sum
    platform: integration
    round: 2
    source: sensor.grid_consumption
    unit_time: h
  - platform: integration
    name: losses_sum
    unique_id: foxess_inv1_losses_sum
    source: sensor.system_losses
    unit_time: h
    method: left
    round: 2

Answered by FozzieUK

Jun 23, 2023

@calum-mcfarlane - The old sensor was a template using the sum of pv1_power + pv2_power as it's source, both of those still exist in the new integration and that's why I said to leave the original PV Power Now template in place as it will continue to provide you with the sum of pv1 + 2 and all your history is intact - also if/when you upgrade the integration everything keeps working.

So just continue to use PV Power Now as you used to, and you've got a 'spare' sensor if in future you decide you want to move to the internally generated PV Power, but other than storage space there is no reason too.

You could remove the integration one from your logger (or disable it) if you want to keep you…

View full answer

FozzieUK · 2023-06-23T11:00:34Z

FozzieUK
Jun 23, 2023

@calum-mcfarlane
The _2 usually means that the sensor is still active when the new modbus sensors are added, but from what you have said they were showing as unavailable which is fine.

Were all the sensors appended with the _2 or just some - do you have any examples of them?

Also when setting up did you set a friendly name or leave blank?

2 replies

calum-mcfarlane Jun 23, 2023
Author

I left the friendly name field blank. I didn't check all the entities but the battery SoC, PV1 and PV2 Power were definitely all "_2".

The "PV Power Now" sensor (probably not its actual name) was unavailable, I presume because it was trying to sum two values that didn't exist anymore?

I can try again and take better notes / pay attention to the right things this time around, today's data is already a mess :)

FozzieUK Jun 23, 2023

Ok, yes best to leave the friendly name as blank.

You removed the pv_power_now which is why it is unavailable, you only needed to remove the first three sensors battery_discharge, battery_charge, grid_consumption - leave pv_power_now, pv_energy_daily and systems_losses all in place for now.

You can tidy up pv_power_now, pv_energy_daily later if you want (I recommended keeping them running for consistency of sensor names in your history) - they are provided internally by the new integration (pv_power_now is called pv_power), (pv_energy_daily is called solar_energy_today)

But you will need to keep the system losses sensor (note the change to feed_in_power sensor in my description is required).

Looks like you have the very latest StealthChesnut version with time periods, you will need to remove all the time period code, it is no longer needed (I think I may need to amend the upgrade notes to reflect this version)

Then if you can re-try what you did, making notes along the way.

I've always added in one extra step (I know others haven't and it works fine), but if you could try and do it like this please -

Remove the line modbus: !include custom_components/foxess/modbus485.yaml
Remove the 3 sensors battery_discharge, battery_charge, grid_consumption only
Remove the 4 time period sensors
change the feed_in_power template to use sensor.feed_in
restart HA (but give it 5 minutes afterwards, the latest version blocks HA shutdown which can take ages)
download Foxess modbus in HACS
restart HA (this is my extra step!)
Go to Settings, Integrations, search and add in the Foxess modbus integration - set it up with your config

Review your sensors

calum-mcfarlane · 2023-06-23T13:17:56Z

calum-mcfarlane
Jun 23, 2023
Author

So - had another go. Followed all your steps, unfortunately seeing the same thing. Specifically:

It seems to collide with pretty much all the sensors in the old integration.

Do I need to go and delete all the "Modbus" sensors before I do the final reboot and install the new integration?

Edit: I'm also wondering if there is a way back from here without restoring my backup, ie can I delete the old Modbus sensors and rename the new FoxESS Modbus sensors, or will that ruin all the history....

22 replies

FozzieUK Jun 23, 2023

I've had to do this a few times on various systems, where you need to go through and remove the _2's... - and the history has always been fine, you shouldn't need the backup.

I never have been able to figure out what triggers it, a hidden internal HA sensor reference that has been corrupted which makes it happen?...... maybe one day we'll find it ;)

Good luck, let us know how it goes 👍

nathanmarlor Jun 23, 2023
Maintainer

@FozzieUK this seems to be quite common and whilst we've done what we can to mitigate it seems to reoccur at random - has anyone reached out to the HA devs to ask for advice? I'd be happy to if not.

calum-mcfarlane Jun 23, 2023
Author

I wonder if it's a Unique ID thing. I've sorted all the sensors that had a "_2" on the end. My old PV Power Now sensor was defined as a template like this:

 - name: "PV Power Now"
      unique_id: foxess_inv1_pv_power_now
      device_class: "power"
      unit_of_measurement: "kW"
      state: >
            {{ (states('sensor.pv1_power') | float(default=0) + states('sensor.pv2_power') | float(default=0) ) * 1 }}

Now I have two, one with my old and one with the new:

I can see PV Now from the new integration is working fine, but being a different sensor name it won't preserve the same history. Could I rename the old sensor to the new name in order to preserve the history, I wonder...

EDIT: No of course I can't, can't have two entities with the same name...

If I rename the new sensor to the old name, am I then effectively forking the integration, would that be something I'd have to update every time I upgraded it?

The issue is that this is one of the data points I do want to track over the longer term...

FozzieUK Jun 23, 2023

@calum-mcfarlane - The old sensor was a template using the sum of pv1_power + pv2_power as it's source, both of those still exist in the new integration and that's why I said to leave the original PV Power Now template in place as it will continue to provide you with the sum of pv1 + 2 and all your history is intact - also if/when you upgrade the integration everything keeps working.

So just continue to use PV Power Now as you used to, and you've got a 'spare' sensor if in future you decide you want to move to the internally generated PV Power, but other than storage space there is no reason too.

You could remove the integration one from your logger (or disable it) if you want to keep your database controlled, you'll have so many new sensors with this integration you'll need to think about what you want to record / monitor anyway.

Answer selected by calum-mcfarlane

calum-mcfarlane Jun 23, 2023
Author

You are of course correct - thanks for the clarification.

What was confusing the heck out of me was that I'd somehow messed up the YAML for the template sensors. However, because the "will HA still boot?" checker was giving me a green light it took me a little while to spot it (you can of course have incorrectly defined sensors that won't stop HA starting, but they won't actually work, either!)

I've got all those templates fixed now so I'm back to logging the right stuff in Maria/Influx. You're right, I will need to look again at my recorder settings and make sure I'm not inadvertently logging stuff I don't need.

FozzieUK Jun 23, 2023

Great stuff, hours of fun 😉

canton7 Jun 23, 2023
Collaborator

Just disable sensors that you don't want (rather than going to the bother of excluding then from the recorder). That means we won't even bother fetching or reporting then to ha, and they won't appear run your sensor list.

FozzieUK Jun 23, 2023

@canton7 actually whilst you mention it, can I double check if you disable the sensors you don’t want do the number of register reads re-calculate.

On the W610 with 8 registers read at a time, the latest version is reporting 83 entities which is getting too close to the 10s poll.. a friends system is reporting lots of ‘previous refresh in process’, i’m just trying to fix it without jumping in my car and swapping him over to UDP 👍

calum-mcfarlane · 2023-06-23T13:51:26Z

calum-mcfarlane
Jun 23, 2023
Author

Seem to have answered my own second question, it does look like if I just delete the old entity and rename the new one the history sorts itself out...

0 replies

FozzieUK · 2023-06-23T14:51:34Z

FozzieUK
Jun 23, 2023

@FozzieUK this seems to be quite common and whilst we've done what we can to mitigate it seems to reoccur at random - has anyone reached out to the HA devs to ask for advice? I'd be happy to if not.

@nathanmarlor No I don't believe so - whenever i've seen it happen (on other peoples systems), it's because of either not removing the old modbus include, or HA being blocked from restarting because of modbus timeouts before the new integration is added - and I suspect part of the problem is that once it goes wrong, you have to delete the integration and all of the _2 sensors or the integration will continue to use them next time it's added.

It happened to me right at the beginning, but that was a definite case of my HA blocking shutdown, i've built maybe 6 systems since and every one has been fine... confusing.. 🤪

It would certainly be helpful to me to understand the mechanism of registering sensors, and whether using different databases (sqlite, mariadb etc..) might be part of it.

4 replies

FozzieUK Jun 23, 2023

@nathanmarlor
Update: just reading through the entity registration process, if i’m reading it correctly unique_id plays a major part in stopping entities being duplicated, so if an entity had a unique_id set, it would prevent other entities taking over that entity_id.
I’m now wondering whether that is what’s caused this to happen as Calum upgraded from the very latest StealthChesnut modbus include file which was fairly recently updated to include unique_id’s to the sensor description - whereas every previous version had no unique_id’s. ??

canton7 Jun 23, 2023
Collaborator

Hah that'll be a bummer - I was the one who contributed those unique_ids!

Although, the H3 yaml has had unique ids for ages, and I'm reasonably sure we've had people with H3s migrate without issue

FozzieUK Jun 23, 2023

🤣 if that’s it i’m not sure there’s much we can do for those using the latest modbus include, other than talk them through the delete and update method that Calum’s just done.

Hopefully there won’t be many of them as new users will likely have gone straight to this integration and won’t have the legacy to worry about.

calum-mcfarlane Jun 23, 2023
Author

Heh, I did update the YAML defining the sensors so they all had unique IDs, could have saved myself the trouble it would seem. This is my /config/custom_components/foxess/modbus485.yaml (no longer in active use but this is what was on the system before I changed things up.

(Yes I was scanning some of the sensors every two seconds, don't judge 😅 )

# v0.9
# Created by https://github.com/StealthChesnut/HA-FoxESS-Modbus
# Modbus Config for Fox ESS Hybrid H1 Inverter
  
# ---------------------------Direct LAN Connection----------------------------------------
#  For use when connecting direct to LAN port of inverter
#
#- name: HA-FoxESS-Modbus-LAN
  type: tcp
  host: !secret ModBusAdapterIP # Set to IP address of the ModBus to TCP adapter
  port: 502
#
# ---------------------------------------------------------------------------
# Uncomment the sensors you wish to use

  sensors:
    - name: "PV1-Voltage"
      unique_id: foxess_inv1_pv1_voltage
      scan_interval: 30
      slave: 247
      address: 11000
      state_class: measurement
      unit_of_measurement: "V"
      data_type: int16
      scale: 0.1
      precision: 1
      input_type: input
      device_class: voltage
    - name: "PV1-Current"
      unique_id: foxess_inv1_pv1_current
      scan_interval: 30
      slave: 247
      address: 11001
      state_class: measurement
      unit_of_measurement: "A"
      data_type: int16
      scale: 0.1
      precision: 1
      input_type: input
      device_class: current
    - name: "PV1-Power"
      unique_id: foxess_inv1_pv1_power
      scan_interval: 2
      slave: 247
      address: 11002
      state_class: measurement
      unit_of_measurement: "kW"
      data_type: int16
      scale: 0.001
      precision: 3
      input_type: input
      device_class: power
    - name: "PV2-Voltage"
      unique_id: foxess_inv1_pv2_voltage
      scan_interval: 30
      slave: 247
      address: 11003
      state_class: measurement
      unit_of_measurement: "V"
      data_type: int16
      scale: 0.1
      precision: 1
      input_type: input
      device_class: voltage
    - name: "PV2-Current"
      unique_id: foxess_inv1_pv2_current
      scan_interval: 30
      slave: 247
      address: 11004
      state_class: measurement
      unit_of_measurement: "A"
      data_type: int16
      scale: 0.1
      precision: 1
      input_type: input
      device_class: current
    - name: "PV2-Power"
      unique_id: foxess_inv1_pv2_power
      scan_interval: 2
      slave: 247
      address: 11005
      state_class: measurement
      unit_of_measurement: "kW"
      data_type: int16
      scale: 0.001
      precision: 3
      input_type: input
      device_class: power
    - name: "Battery-SoC"
      unique_id: foxess_inv1_battery_soc
      scan_interval: 30
      slave: 247
      address: 11036
      state_class: measurement
      unit_of_measurement: "%"
      data_type: int16
      input_type: input
      device_class: battery
    - name: "Battery-Temp"
      unique_id: foxess_inv1_battery_temperature
      scan_interval: 60
      slave: 247
      address: 11038
      state_class: measurement
      unit_of_measurement: "°C"
      scale: 0.1
      precision: 1
      data_type: int16
      input_type: input
      device_class: temperature
    - name: "Battery-Discharge-Power"
      unique_id: foxess_inv1_battery_power
      scan_interval: 2
      slave: 247
      address: 11008
      state_class: measurement
      unit_of_measurement: "kW"
      data_type: int16
      scale: 0.001
      precision: 3
      input_type: input
      device_class: power
    - name: "Load Power"
      unique_id: foxess_inv1_load_power
      scan_interval: 2
      slave: 247
      address: 11023
      state_class: measurement
      unit_of_measurement: "kW"
      data_type: int16
      scale: 0.001
      precision: 3
      input_type: input
      device_class: power
    - name: "InvBatVolt"
      unique_id: foxess_inv1_inverter_battery_voltage
      scan_interval: 30
      slave: 247
      address: 11006
      state_class: measurement
      unit_of_measurement: "V"
      data_type: int16
      scale: 0.1
      precision: 1
      input_type: input
    - name: "InvBatPower"
      unique_id: foxess_inv1_inverter_battery_power
      scan_interval: 2
      slave: 247
      address: 11007
      state_class: measurement
      unit_of_measurement: "kW"
      data_type: int16
      scale: 0.01
      precision: 2
      input_type: input
    - name: "RVolt"
      unique_id: foxess_inv1_grid_voltage_R
      scan_interval: 30
      slave: 247
      address: 11009
      state_class: measurement
      unit_of_measurement: "V"
      data_type: int16
      scale: 0.1
      precision: 1
      input_type: input
      device_class: voltage
    - name: "RCurrent"
      unique_id: foxess_inv1_inv_current_R
      scan_interval: 30
      slave: 247
      address: 11010
      state_class: measurement
      unit_of_measurement: "A"
      data_type: int16
      scale: 0.1
      precision: 1
      input_type: input
      device_class: current
    - name: "RFreq"
      unique_id: foxess_inv1_grid_frequency
      scan_interval: 30
      slave: 247
      address: 11014
      state_class: measurement
      unit_of_measurement: "Hz"
      data_type: int16
      scale: 0.01
      precision: 3
      input_type: input
      device_class: frequency
    - name: "EPS RVolt"
      unique_id: foxess_inv1_eps_rvolt
      scan_interval: 30
      slave: 247
      address: 11015
      state_class: measurement
      unit_of_measurement: "V"
      data_type: int16
      scale: 0.1
      precision: 1
      input_type: input
    - name: "Grid CT"
      unique_id: foxess_inv1_grid_ct
      scan_interval: 2
      slave: 247
      address: 11021
      state_class: measurement
      unit_of_measurement: "kW"
      data_type: int16
      scale: 0.001
      precision: 3
      input_type: input
    - name: "CT2 Meter"
      unique_id: foxess_inv1_ct2
      scan_interval: 1
      slave: 247
      address: 11022
      state_class: measurement
      unit_of_measurement: "kW"
      data_type: int16
      scale: 0.001
      precision: 3
      input_type: input
    - name: "InvTemp"
      unique_id: foxess_inv1_inverter_temperature
      scan_interval: 30
      slave: 247
      address: 11024
      state_class: measurement
      unit_of_measurement: "°C"
      data_type: int16
      scale: 0.1
      precision: 1
      device_class: temperature
      input_type: input
    - name: "AmbTemp"
      unique_id: foxess_inv1_ambient_temperature
      scan_interval: 30
      slave: 247
      address: 11025
      state_class: measurement
      unit_of_measurement: "°C"
      data_type: int16
      scale: 0.1
      precision: 1
      device_class: temperature
      input_type: input
    - name: "BatVolt"
      unique_id: foxess_inv1_battery_voltage
      scan_interval: 30
      slave: 247
      address: 11034
      state_class: measurement
      unit_of_measurement: "V"
      data_type: int16
      scale: 0.1
      precision: 1
      device_class: voltage
      input_type: input
    - name: "Temp"
      unique_id: foxess_inv1_temperature
      scan_interval: 30
      slave: 247
      address: 11035
      state_class: measurement
      unit_of_measurement: "°C"
      data_type: int16
      scale: 0.1
      precision: 1
      device_class: temperature
      input_type: input
    - name: "Min SoC"
      unique_id: foxess_inv1_min_soc
      scan_interval: 60
      slave: 247
      address: 41009
      state_class: measurement
      unit_of_measurement: "%"
      data_type: int16
      input_type: input
      device_class: battery
    - name: "Min SoC (On Grid)"
      unique_id: foxess_inv1_min_soc_on_grid
      scan_interval: 60
      slave: 247
      address: 41011
      state_class: measurement
      unit_of_measurement: "%"
      data_type: int16
      input_type: input
      device_class: battery
    - name: "Time Period 1 - Start"
      unique_id: foxess_inv1_time_period_1_start
      address: 41002
      scan_interval: 60
      slave: 247
      input_type: input
    - name: "Time Period 1 - End"
      unique_id: foxess_inv1_time_period_1_end
      address: 41003
      scan_interval: 60
      slave: 247
      input_type: input
    - name: "Time Period 2 - Start"
      unique_id: foxess_inv1_time_period_2_start
      address: 41005
      scan_interval: 60
      slave: 247
      input_type: input
    - name: "Time Period 2 - End"
      unique_id: foxess_inv1_time_period_2_end
      address: 41006
      scan_interval: 60
      slave: 247
      input_type: input

    - name: "BMS Cell mV High"
      unique_id: foxess_inv1_bms_cell_mv_high
      address: 11045
      scan_interval: 5
      slave: 247
      input_type: input
      device_class: voltage
      unit_of_measurement: "mV"
    - name: "BMS Cell mV Low"
      unique_id: foxess_inv1_bms_cell_low
      address: 11046
      scan_interval: 5
      slave: 247
      input_type: input
      device_class: voltage
      unit_of_measurement: "mV"
    - name: "BMS Charge Rate"
      unique_id: foxess_inv1_bms_charge_rate
      address: 11041
      scan_interval: 30
      slave: 247
      input_type: input
      device_class: current
      unit_of_measurement: "A"
      scale: 0.1
    - name: "BMS Discharge Rate"
      unique_id: foxess_inv1_bms_discharge_rate
      address: 11042
      scan_interval: 30
      slave: 247
      input_type: input
      device_class: current
      unit_of_measurement: "A"
      scale: 0.1
    - name: "BMS Cell Temp Low"
      unique_id: foxess_inv1_bms_cell_temperature_low
      scan_interval: 30
      slave: 247
      address: 11044
      state_class: measurement
      unit_of_measurement: "°C"
      data_type: int16
      scale: 0.1
      precision: 1
      device_class: temperature
      input_type: input
    - name: "BMS Cell Temp High"
      unique_id: foxess_inv1_bms_cell_temperature_high
      scan_interval: 30
      slave: 247
      address: 11043
      state_class: measurement
      unit_of_measurement: "°C"
      data_type: int16
      scale: 0.1
      precision: 1
      device_class: temperature
      input_type: input
    - name: "BMS Watthours Total"
      unique_id: foxess_inv1_bms_watthours_total
      address: 11049
      scan_interval: 60
      slave: 247
      input_type: input
      unit_of_measurement: "Ah"
      device_class: energy
    - name: "BMS kWh Remaining"
      unique_id: foxess_inv1_bms_kwh_remaining
      address: 11037
      scan_interval: 60
      slave: 247
      input_type: input
      scale: 0.01
      precision: 2
      device_class: energy
      unit_of_measurement: "kWh"

  binary_sensors:
    - name: "Time Period 1 - Enabled"
      unique_id: foxess_inv1_time_period_1_enabled
      address: 41001
      scan_interval: 60
      slave: 247
      input_type: input
    - name: "Time Period 2 - Enabled"
      unique_id: foxess_inv1_time_period_2_enabled
      address: 41004
      scan_interval: 60
      slave: 247
      input_type: input

  # !include sensors.yaml

calum-mcfarlane · 2023-06-23T15:26:06Z

calum-mcfarlane
Jun 23, 2023
Author

🤣 if that’s it i’m not sure there’s much we can do for those using the latest modbus include, other than talk them through the delete and update method that Calum’s just done.

Hopefully there won’t be many of them as new users will likely have gone straight to this integration and won’t have the legacy to worry about.

If you deleted all the old sensors en masse before you installed the new integration from HACS, presumably all the new sensors wouldn't get _2 appended to them, and the whole thing would be an awful lot simpler 🤣

Feels like a note to say "if you have unique IDs in your YAML then you want to do this extra step" would handle it?

1 reply

canton7 Jun 23, 2023
Collaborator

We're not yet sure whether the unique_ids are the cause, I think.

The integration could also do things to help the migration potentially. We can possibly manipulate the entity database before registering our own entities.

FozzieUK · 2023-06-24T08:41:30Z

FozzieUK
Jun 24, 2023

I just tried a quick test with a template sensor, I created a sensor called batt_discharge_w (sensor.battery_discharge*1000) with it's own unique_id, and checked it was reporting ok, I then removed the template, refreshed templates so it was showing as unavailable.

Then replaced it with the same sensor name but one digit different in the unique_id and this is what I got -

It looks like once the unique_id has been set you can't replace the entity, you have to delete the old entity which removes it's registration entry, then rename the new entity (or manually edit the core.entity_registry in the .storage directory.)

  {
    "aliases": [],
    "area_id": null,
    "capabilities": null,
    "config_entry_id": null,
    "device_class": null,
    "device_id": null,
    "disabled_by": null,
    "entity_category": null,
    "entity_id": "sensor.batt_discharge_w",
    "hidden_by": null,
    "icon": null,
    "id": "bc66de151ee58a3c3ca4013fb111631d",
    "has_entity_name": false,
    "name": null,
    "options": {
      "conversation": {
        "should_expose": false
      }
    },
    "original_device_class": "battery",
    "original_icon": null,
    "original_name": "Batt_discharge_W",
    "platform": "template",
    "supported_features": 0,
    "translation_key": null,
    "unique_id": "9c7fbc3-0678-1234",
    "unit_of_measurement": "W"
  },
  {
    "aliases": [],
    "area_id": null,
    "capabilities": null,
    "config_entry_id": null,
    "device_class": null,
    "device_id": null,
    "disabled_by": null,
    "entity_category": null,
    "entity_id": "sensor.batt_discharge_w_2",
    "hidden_by": null,
    "icon": null,
    "id": "8d59353cb355b11af4944146065ff46b",
    "has_entity_name": false,
    "name": null,
    "options": {
      "conversation": {
        "should_expose": false
      }
    },
    "original_device_class": "battery",
    "original_icon": null,
    "original_name": "Batt_discharge_W",
    "platform": "template",
    "supported_features": 0,
    "translation_key": null,
    "unique_id": "9c7fbc3-0678-1534",
    "unit_of_measurement": "W"
  }

1 reply

canton7 Jun 24, 2023
Collaborator

Interesting, thanks!

We can modify the entity registry from code I think, so we could do something about removing all entities whose unique_ids starts with foxess_inv1. Ir maybe we can remove/change just the unique_id. I'm not sure what would be safe...

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Migrating over from StealthChesnut integration (finally) - how to avoid duplicate sensors? #342

{{title}}

Replies: 6 comments 30 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Select a reply

Migrating over from StealthChesnut integration (finally) - how to avoid duplicate sensors? #342

Replies: 6 comments · 30 replies

calum-mcfarlane Jun 23, 2023 Author

calum-mcfarlane Jun 23, 2023 Author

nathanmarlor Jun 23, 2023 Maintainer

calum-mcfarlane Jun 23, 2023 Author

calum-mcfarlane Jun 23, 2023 Author

canton7 Jun 23, 2023 Collaborator

calum-mcfarlane Jun 23, 2023 Author

canton7 Jun 23, 2023 Collaborator

calum-mcfarlane Jun 23, 2023 Author

calum-mcfarlane Jun 23, 2023 Author

canton7 Jun 23, 2023 Collaborator

canton7 Jun 24, 2023 Collaborator

Replies: 6 comments 30 replies

calum-mcfarlane Jun 23, 2023
Author

calum-mcfarlane
Jun 23, 2023
Author

nathanmarlor Jun 23, 2023
Maintainer

calum-mcfarlane Jun 23, 2023
Author

calum-mcfarlane Jun 23, 2023
Author

canton7 Jun 23, 2023
Collaborator

calum-mcfarlane
Jun 23, 2023
Author

canton7 Jun 23, 2023
Collaborator

calum-mcfarlane Jun 23, 2023
Author

calum-mcfarlane
Jun 23, 2023
Author

canton7 Jun 23, 2023
Collaborator

canton7 Jun 24, 2023
Collaborator