input_text limited to 255 Characters so won't Hold Five alert IDs about weatheralerts

[regularguy01]

I fixed this by adding

.split('urn:oid:2.49.0.1.840.0.')[1],

on line 193 of sensor.py

the full line looks like
"id": properties.get("id", "null").split('urn:oid:2.49.0.1.840.0.')[1],

The URN (universal registered number) never changes for NWS and is specific to the USA.

Then you don't need yaml

[jlverhagen]

Thanks for the report. The NWS changed the alert ID format at some point and made them much longer. I think I can fix it by adding a second input_text helper and splitting the alert IDs between two input_text helpers. It should only take some minor adjustments to the UI Notification automation.

[kaijk]

Thanks for your attention to this. We happen to have some residual/reappearing winter that is generating a flurry ;) of NWS alerts that make for good testing.

Might you use an attribute to store these data? Attributes are not bound by the 255 character limit for an entity's state .

[mjnovotny82]

We could pipe in a replace() to remove urn:oid:2.49.0.1.840.0. from the alert IDs in your weatheralerts.yaml file. You would want to add | replace('urn:oid:2.49.0.1.840.0.','') to each of the five [0-4] alert_id sections . This should drop it down to around 234 characters.

Before

      alert_id: >-
        {% if not is_state('sensor.weatheralerts_1', '0') and not is_state('sensor.weatheralerts_1', 'unavailable') and not is_state('sensor.weatheralerts_1', 'unknown') and is_state('sensor.weatheralerts_1_alert_1', 'on') or (is_number(states('sensor.weatheralerts_1')) and (states('sensor.weatheralerts_1')|int > 0)) %}
          {{ states.sensor.weatheralerts_1.attributes.alerts[0].id }}
        {% else %}
          None
        {% endif %}
    # skip some lines #
      alert_id: >-
        {% if not is_state('sensor.weatheralerts_1', 'unavailable') and not is_state('sensor.weatheralerts_1', 'unknown') and is_state('sensor.weatheralerts_1_alert_2', 'on') or (is_number(states('sensor.weatheralerts_1')) and (states('sensor.weatheralerts_1')|int > 1)) %}
          {{ states.sensor.weatheralerts_1.attributes.alerts[1].id }}
        {% else %}
          None
        {% endif %}

After

      alert_id: >-
        {% if not is_state('sensor.weatheralerts_1', '0') and not is_state('sensor.weatheralerts_1', 'unavailable') and not is_state('sensor.weatheralerts_1', 'unknown') and is_state('sensor.weatheralerts_1_alert_1', 'on') or (is_number(states('sensor.weatheralerts_1')) and (states('sensor.weatheralerts_1')|int > 0)) %}
          {{ states.sensor.weatheralerts_1.attributes.alerts[0].id | replace('urn:oid:2.49.0.1.840.0.','') }}
        {% else %}
          None
        {% endif %}
    # skip some lines #
      alert_id: >-
        {% if not is_state('sensor.weatheralerts_1', 'unavailable') and not is_state('sensor.weatheralerts_1', 'unknown') and is_state('sensor.weatheralerts_1_alert_2', 'on') or (is_number(states('sensor.weatheralerts_1')) and (states('sensor.weatheralerts_1')|int > 1)) %}
          {{ states.sensor.weatheralerts_1.attributes.alerts[1].id | replace('urn:oid:2.49.0.1.840.0.','') }}
        {% else %}
          None
        {% endif %}
    # rinse and repeat for [2], [3], [4] #

I have not see urn:oid:2.49.0.1.840.0. changed in year plus of using weatheralerts.

[kaijk]

I'm trying your suggestion @mjnovotny82. We should be having a full compliment of alerts over the next few days.

I'd also considered using an attribute for the data instead of a state, but haven't pursued it.