Possible Bug with KW13 Temperature Data in Automation

I have an automation where I want to turn on a light with certain settings based on the temperature outside. I am using the following code to check the state of the kw13 Temperature entity.

- conditions:
          - condition: numeric_state
            entity_id: sensor.kw13_temperature
            above: 29.9
            below: 40
          sequence:
          - service: light.turn_on
            metadata: {}
            data:
              color_name: darkblue
              brightness: 100
              transition: 5
            target:
              entity_id: light.master_light_on_off

When I am editing the automation through the gui, I can Test the condition and either get a “Condition Passes” or “Condition did not pass” result. However, when the automation runs based on the defined trigger, it fails and the trace shows an error stating essentially that the state of kw13_temperature could not be processed as a numeric_state (sorry, I don’t have exact error now but can get it later).

Unless someone knows of something different to check/test, I can only think there is some sort of bug that causes the trigger-activated conditional test to apply differently than the manual condition test from the automation editor gui.

The full error in the trace is

Error: In ‘numeric_state’ condition: entity sensor.kw13_temperature state ‘Data from National Weather Service/NOAA’ cannot be processed as a number

However, as mentioned in my initial comment, if I test the condition on the Automation gui, it gives me a valid pass/fail response.

What is the actual state of that sensor when you look in developer tools > states

The state is the current temp to the tenth of a degree, e.g. 59.7 at this time

The trace clearly shows that the state of the sensor at the time of evaluation is the text “Data from National Weather Service/NOAA”.

Please show a screenshot of the sensor from Developer Tools / States showing the state and attributes; and the full YAML for the whole automation. My guesses:

  • you’re referring to the wrong sensor
  • you’ve inadvertently selected an attribute in the GUI

I can virtually guarantee that this is an error on your part or the sensor state changing between text and number, rather than a bug.

Here is the state:
Screenshot_20240409_090311
Huh, today when I check the trace it looks like it did actually run. I didn’t change anything with the automation script. Is there a way to see trace history outside of the past 24 hours? It only allows me to see the past few runs but I can’t go back far enough to see if I received the error message the last time this section of the code ran. It’s a longer script and it doesn’t run this section every time it triggers. I’ll do some more testing and see if it’s actually happy now for whatever reason.

I also could use some help with the efficiency of this script. I have a section of conditions that are really ugly
Screenshot_20240409_091123
This uses the code I posted in the original comment. The only thing that changes in each condition section is the above/below and color_name values.

Is there a way to use a template or variable so that I don’t have to duplicate that whole section for each range check?

I asked for the attributes too, like this:

No. You can increase the number of traces but not retrospectively. You can check the past states of the temperature sensor though — if it has a unit_of_measurement defined (which I’d know if you’d included attributes as requested above), there will be errors in the logs if it was returning a non-numeric value.

Post the whole automation code (as requested above) and we can have a look.

This pointed me in the right direction. I didn’t realize Data from National Weather Service/NOAA was actually the value it was reading from the sensor. I then found the attribute with that value and realized what was wrong in the code. Everything seems to be set up correctly now. Thanks for the help!