Multiple bitmap lookups?

[frsantos]

Hi,

In the KSTAR Hybrid integration, I have several alarm/error codes that come from a bitmap lookup. For example, the DSP alarm code sensor is a U32 value which has a lookup table like the following:

Currently I read the value as bits with rule: 6, so in the last couple of days, it has had the following values:

During the night it has value 0x2090, which translates to codes W04, W07 and W13. In the morning it moves to 0x2080 (W07 and W13), then to 0x80 (W07) and finally to no alarm (0x0) when it is properly producing in the morning.

I have several bitmap lookup tables like this. What would be the best way of setting this in the profile definition? I don't want to add 100+ sensors for each different bit on each of the different sensors that have this kind of lookup.

[davidrapan]

Yeah this also came to my mind when I was refactoring Alarm sensor for the SG0??P3 😉 and added during that period masking according index using bit property which should be also possible to implement for lookup sensors. Not yet done though but will be in the future proly by extending property set for current tables. So instead of key you will just say which bit has to be set....

[frsantos]

Yes, the lookup by bit instead of whole value would be perfect, but how about the multiple values? Should they be concatenated together?

W04 - Solar Loss
W07 - Bat Volt Low
W13 - Bat Cap Under

W07 - Bat Volt Low
W13 - Bat Cap Under

[davidrapan]

Guess that could be solved by non-exclusivity.

[frsantos]

Guess that could be solved by non-exclusivity.

What do you mean by "non-exclusivity"?

[gedger]

My Solis inverter uses a lot of bit fields, in theory each bit should be mapped to a binary sensor which is what I've done although I've only mapped the bits that I need rather than the 100s available though.

However, I've discovered several of the bits are mutually exclusive so could be combined into one sensor. For instance the running normally bit is never set at the same time as the initialising bit nor the standby bit which makes sense but anither model may work differently.

I currently read the whole bit field and then decode the individual bits like this.

      #  the combination of all the working status bits decoded below
      - name: "Working Status"
        rule: 1
        registers: [3071]
        icon: "mdi:list-status"

      # The Normal state of inverter e.g. it is operating normally
      - name: "WStatus Normal"
        platform: "binary_sensor"
        device_class: "running"
        bit: 0
        rule: 1
        registers: [3071]
        icon: "mdi:solar-power"

      # set briefly whilst the inverter initialises.
      - name: "WStatus Initialising"
        platform: "binary_sensor"
        bit: 1
        rule: 1
        registers: [3071]
        icon: "mdi:restart"

      # set true when the grid has failed hence the invert
      - name: "WStatus Grid Status"
        platform: "binary_sensor"
        device_class: "power"
        inverted: true
        bit: 2
        rule: 1
        registers: [3071]
        icon: "mdi:transmission-tower-off"

      # set briefly before the inverter goes into standby overnight
      - name: "WStatus Standby"
        platform: "binary_sensor"
        bit: 4
        rule: 1
        registers: [3071]
        icon: "mdi:power-standby"

      # If the inverter is derating it's output due to operating conditions e.g. over voltage
      - name: "WStatus Derating"
        platform: "binary_sensor"
        bit: 5
        rule: 1
        registers: [3071]
        icon: "mdi:speedometer-medium"

      # If the inverter output is being limited e.g. my limiting the max power output
      - name: "WStatus Limiting"
        platform: "binary_sensor"
        bit: 6
        rule: 1
        registers: [3071]
        icon: "mdi:speedometer-slow"

      - name: "Temperature"
        device_class: "temperature"
        state_class: "measurement"
        uom: "°C"
        scale: 0.1
        rule: 2
        registers: [3041]
        icon: "mdi:thermometer"

a more efficient syntax could be as follows, the binary sensor is assumed as it couldn't be anything else. device_class, state_class, icon being optional and used as needed.

- name: "Working Status"
  rule: 1
  registers: [3071]
  bit_lookup:
    - bit 0: 
      value: "WStatus Normal"
    - bit 1:
      value: "WStatus Initialising"
      icon: "mdi:restart"
    - bit2:
      value: "WStatus Grid Status"
      device_class: running
    - bit4:
      value: "WStatus Standby"

[frsantos]

In my case, they are not mutually exclusive, as I shown in the main description. You can have many error codes at the same time, so this is not feasible for me.

[davidrapan]

I agree. That's why it would be non-exclusive lookup. 😉

[frsantos]

So, we'd need something like bit_lookup for mutually exclusive and a different bit_lookup_multiple for not exclusive.

[gedger]

Each bit creates a completely separate binary sensor so they are exclusive I just happened to notice that some seem to be mutually exclusive but I leave them as exclusive. All bit fields must be considered exclusive in my view.

[davidrapan]

Yeah well we don't know that. And proly never will.