Round sensor value

I use HA (self hosted) to control my shelly TRVs. I query the Shelly’s every 10 minutes and depending on the returned room temperature and value of the radiator valve, the valve is opened or closed. I’m using 2 automations for that:

Temperature is below 22 degrees and valve is below 100 then open the valve (to 100%)
Temperature is above 22 degrees and valve is above 0 then close the valve (to 0%)

The reason why I check the valve value is, that it makes no sense to open the valve if it is aready open and vice-versa.

This is working very well but sometimes it happens that the returned value of the valve is not 0 or 100 it’s something like e.g. 99.95. In this case the automation stops working.

Is it possible to round the value of the valve? So 99,95 gets rounded to 100.

Below is my current automation:

alias: Room temperature beyond 22 degrees
trigger:
  - platform: time_pattern
    minutes: /10
condition:
  - condition: and
    conditions:
      - type: is_temperature
        condition: device
        device_id: bfffb30a5361a82833c4078a2ba4e98b
        entity_id: 294ac34c0a94795c7f752f20bfaf003e
        domain: sensor
        below: 22
      - condition: numeric_state
        entity_id: number.shelly_vz_valve_position
        below: 100
action:
  - device_id: d6c139d18e64c0e048e9fa3aa9f8270f
    continue_on_error: true
    domain: number
    entity_id: e39fbba3e6f0f4092ef29411db328f58
    type: set_value
    value: 100
mode: single

Hi, welcome. For us you be able to help you with your code, you need to format it properly, because indentation matters in yaml, and like this it is i possible to see what is there. See point 11 in this post:

Then, to get to your question, avoid device actions whenever you can:

Second, using a time based condition for this is not the best way. Home assistant is event based. So use a trigger on what could happen to need action, and not check on a time basis. It will keep home assistant needlessly busy, and it will be slow to respond instead of immediate.

Instead of rounding, it looks like you could better make use of a numerical state condition, and use e.g. below 99.5 as the condition. But I fail to see why that would be the problem here. You can always slightly adjust the bound you test for, so testing below 99.5 would do the same as rounding.

Using the automation trace will tell you what condition failed.

I’m curious as to what the shelly will do if you tell it to open and its already open.

Hi Edvin,

I have formated the code for better reading.

I know that it is better to use entity than device but unfortunately there is no option to use “valve value” within the entity. It is simply not there/available, only when I use device.

The problem with my scenario is, that in case a value of e.g 99,95 instead of 100 is reported, the automation continues (because of continue_on_error: true) but the action is no longer executed.

Using the time based polling is working quite well in my case. HA is running as VM on a ESX server with almost zero load.

CPU: 4 cores assigend / average usage 98 MHz (capacity: 12 cores, 20 GHz)
Memory: 4 GB assigned / 1.66 GB used

I had hoped there would be some math function available to round the returned value of a sensor :slightly_smiling_face:

I’m curious as to what the shelly will do if you tell it to open and its already open.

Unfortunately I cannot remember exactly as it was during winter time when I played with that. So far as I remember shelly tries to move it, even if it is already open. This has 2 disadvantages: it consumes battery unnecessarily and the bigger pain: valve movement causes noise and this is no fun in the bedroom.

Doesn’t the TRV create a climate entity by itself?
Not sure why you need the automation because a climate entity can do this by itself

That is extremely unlikely. Look at its state in the developer tools, and you’ll see the value you are after. If it is not the state, it is in the attributes. For the valve integration, the state is open/close, the position is in the attributes. You can use both in state/numeric state triggers and conditions. If it were not, it would also be impossible to create a template for it.

If there is a comma in the value then that would be an error that cannot be solved by rounding either. But if it is a decimal point, the condition is false, it is not an error if the condition is false. continue_on_error only applies to ‘real’ errors.