Using probe status updates in automations

[sddgit]

Hi. I’d like to trigger an automation whenever a new reading comes in, and do something with that reading. I’m thinking that maybe some sort of mqtt trigger might do the trick (one for each probe type I guess). But I’m completely out of my depth here. Is this possible? If so, what sort of automation code would I need?

Thank you for this amazing integration.

[LordMike]

Hi,

You can trigger automations in Home assistant using a variety of triggers. You could use MQTT as the trigger, or you could react to changes to a device or sensor entity. I think you want to do the latter, as this would be after interpretation by HASS about the data etc.

Note that BR2MQTT will avoid sending updates that don't change any data. You can either enable sending always (see BlueRiiot__ReportUnchangedValues), or find a value that changes on every update (like the "last_contact" sensor).

For MQTT debugging, I recommend MQTT Explorer.

Mike.

[sddgit]

Thanks very much for the reply. You have given me something go to go on, I think.

Let me explain what I'm trying to do. As I'm sure you know, readings taken when the filter pump isn't running aren't that accurate. That's why the Blueriiot app has the scheduling thing, which I know I can change via your integration. But my schedules change often, based on automation of things like solar forecasting. I know I could probably come up with something to automate the updating of the Blueriiot schedule, but it would mean a lot of work to integrate with my own scheduling (and a lot of learning!). I thought it would be good to have an automation that was triggered whenever readings enter HA, and that automation could check whether the filter pump is running. If so, the various readings could be copied to something like an input_number, and that is what is used in the GUI. So the input_numbers contain either "live" readings or the readings from when the pump was last running.

I hadn't thought of using the "last contact" sensor as the automation trigger. I think this would fit the bill nicely...

[LordMike]

There was another issue regarding filter pumps, where I think my comment was that it would probably be easier for me to make a "pause readings" than it would be for everyone else to make changes on their end to account for non-running pumps.

See #17

[sddgit]

Yes, that issue resulted in you implementing the whole pump schedule thing. For me, even a “pause readings” option would be a bit too much trouble, given my ever changing schedules. I’ve now implemented this automation:

alias: Update Pool Data While Filter Running
description: ''
trigger:
  - platform: state
    entity_id: sensor.blue_xxxxxxx_last_contact
condition:
  - condition: device
    type: is_on
    device_id: 93d4bbc6fdd61b6affb3b66f33684739
    entity_id: switch.pool_filter
    domain: switch
    for:
      hours: 0
      minutes: 5
      seconds: 0
      milliseconds: 0
action:
  - service: input_number.set_value
    target:
      entity_id: input_number.orp_while_filter_running
    data:
      value: '{{ states(''sensor.pool_orp'') | int }}'
  - service: input_number.set_value
    target:
      entity_id: input_number.ph_while_filter_running
    data:
      value: '{{ states(''sensor.pool_ph'') | float }}'
  - service: input_number.set_value
    target:
      entity_id: input_number.salinity_while_filter_running
    data:
      value: '{{ (states(''sensor.pool_salinity'') | float *1000) | int }}'
  - service: input_number.set_value
    target:
      entity_id: input_number.temperature_while_filter_running
    data:
      value: '{{ states(''sensor.pool_temperature'') | float }}'
mode: single

This copies out all the readings whenever an update occurs, but only if the pump has been running for 5 minutes. One question - once this triggers, will all the sensors always be immediately available, or should I insert a small pause before copying them out?

Still one puzzle. Despite using int for ORP and Salinity, those input_numbers always display with a trailing .0. Any ideas on that one?

[LordMike]

All the entities should be available at all times, assuming all you do is this copy-script. This means all sensors are always available and receive (possibly bogus) readings.

The presentation of your salinity probably doesn't have anything to do with your jinja2 cast to int - but the type of the entity. HASS presents values to you differently than how they're stored.

To confirm, I did this in HASS developer tools:

[sddgit]

To be clear, I meant that at the instant the automation is triggered (because the “last contact” sensor has been updated), will all the other measurement sensors contain what was fetched, or might your code still be busy populating them?

Yes, the templates for salinity and ORP produce whole numbers. But when that is copied to an input_number, that then contains the trailing “.0” when displayed. So is that just the way it is, and I have to find another way to strip off the trailing “.0”?

Really appreciate all your help.

[LordMike]

No idea how to clear up that, then.

There could definitely be a delay between the different entities being updated - I don't think I can control it.

[sddgit]

I got round it by creating template sensors:

  - name: "Salinity Whole Number"
    state: "{{ states('input_number.salinity_while_filter_running') | int }}"
  - name: "ORP Whole Number"
    state: "{{ states('input_number.orp_while_filter_running') | int }}"

Still don’t know why that’s necessary, but oh well!

I might add, say, a 5 second delay in the automation then, after it’s triggered and before the sensors are copied out. Hopefully that will make it safe!

Thanks again for your kind help, and for the project. Couldn’t do without it!