[Feature Request] Add body_contains, received_date/time, etc. to query_sensor configuration variables

[GitHubGoody]

Can you please add a body_contains configuration variable to the query_sensor? It would be nice if it could accept a list of options, but a single string would probably work for many situations. Thank you.

[RogerSelwyn]

I don’t believe the O365 api supports this, but I’ll take a look tomorrow.

[RogerSelwyn]

Looks like it can be done, so I'll try and get it added in the next couple of days/

[RogerSelwyn]

Looks like I spoke to soon, I'll investigate more

2022-05-19 20:13:21 ERROR (SyncWorker_2) [O365.connection] Client Error: 400 Client Error: Bad Request for url: https://graph.microsoft.com/v1.0/me/mailFolders/Inbox/messages?%24top=2&%24filter=receivedDateTime+ge+1900-05-01T00%3A00%3A00%2B00%3A00+and+contains%28body%2C+%27eBay%27%29&%24orderby=receivedDateTime+desc | Error Message: Invalid filter clause

[GitHubGoody]

Thanks! While trying to configure some automations, I think other variables would be equally helpful.

I scraped the attributes from a query. While you're adding body, would it be a big deal to add the rest?

Requested:

• body
• received (format is 2022-05-19T12:35:43+0000)
  • date_received (definitely would be helpful)
  • time_received_before and time_received_after (there may be a better way to implement)
• to
• cc

Implemented:

• subject
• sender
• has_attachments
• importance
• is_read
• attachments

Not needed:

• bcc (not even sure why this is in the payload since it should always be empty)

[RogerSelwyn]

If you can provide the query that would help, since so far I'm failing on body.

[GitHubGoody]

I think you're asking for a sample query. If something like this worked, I think my use case would be good to go:

      query_sensors:
        - name: "herecomesthebus"
          folder: "Inbox/Here Comes the Bus"
          max_items: 2
          from: "[email protected]"
          date_received: The right syntax for now().year-now().month-now() or explicit as "2022-05-19"
          body_contains: "FIRSTNAMEOFONEOFMYCHILDREN"

With this, I would be able to program automations each day when sensor.herecomesthebus incremented to 1 in the AM and 2 in the afternoon. Then it would auto reset to 0 each night at midnight.

[RogerSelwyn]

No :-) You said you scraped the attributes from a query, which implies that you have a working graph api query that works.

[RogerSelwyn]

OK, I've found it can be done, but I'm going to have to request a change to the O365 module that does the actual calls to the api. It might take a while for them to release a new version.

O365/python-o365#782

[GitHubGoody]

No :-) You said you scraped the attributes from a query, which implies that you have a working graph api query that works.

Oh, sorry. I'm probably misusing the term "scrape." #notacoder. I just meant I went to the Developer tab in HA and pulled up one of the query sensors to see the values already being passed in the data attribute. I posted all of those fields ~5 replies up.

OK, I've found it can be done, but I'm going to have to request a change to the O365 module that does the actual calls to the api. It might take a while for them to release a new version.

Nice!

In the meantime, I may be able to get what I need directly from the data already in the sensor attribute. I'm trying to play with the template now:

{% if "FIRSTNAMEOFONEOFMYCHILDREN" in state_attr('sensor.herecomesthebus','data') %}
    true
{% else %}
    false
{% endif %}

It's not working...yet ;-)

[RogerSelwyn]

The data attribute is an array, so you will need to iterate the array. I'm afraid I don't use the inbuilt HA automation, so not sure how that is done.

[GitHubGoody]

Ah, of course. I'll Google-Fu my way to that answer. Thanks!

EDIT:

{% set DTG_received = state_attr('sensor.herecomesthebus','data')[0]['received'] %}
{% set Day_received = DTG_received[8:10] %}
{% if Day_received == now().day|string %}
true
{% else %}
false
{% endif %}

[RogerSelwyn]

Filter on 'to' and 'cc' is not possible with the MS Graph api as it stands.

[RogerSelwyn]

• received (format is 2022-05-19T12:35:43+0000)

  • date_received (definitely would be helpful)
  • time_received_before and time_received_after (there may be a better way to implement)

Whilst in theory I can support hard coded dates, it doesn't really make sense since whenever you want to change the date you would need to edit the config and then restart HA.

With the calendars, there is rolling window which is entered in calendars.yaml. To be honest I'm not sure of the value of a window that is the past for email and clearly no value for the future. So to me it only makes sense to show mails that are current which is what the integration provides today.

Perhaps you can articulate a use case for filtering on date_received.

[GitHubGoody]

Here's my first of what I think would be many use cases for me. My children ride the bus to/from school. This service sends me an e-mail at a configurable distance from their stop. I'd like to establish a query sensor with a state that alters between 0 and 1,that I can essentially use as a binary based on:

• folder
• sender
• date_received = today
• body_contains = firstnameofoneofmychildren
• (hopefully) time_received >min and <max to filter the AM from PM notifications

The date would be compared to now() and the time windows would be static enough for each sensor (e.g. 7:00-8:00 and 15:00-16:00).

Something like this...

      query_sensors:
        - name: "herecomesthebus"
          folder: "Inbox/Here Comes the Bus"
          max_items: 2
          from: "[email protected]"
          date_received: The right syntax for now().year-now().month-now()...essentially today()
          time_received_min: 7:00
          time_received_max: 8:00
          body_contains: "FIRSTNAMEOFONEOFMYCHILDREN"

When the message hits the folder above, sensor.herecomesthebus would go from 0 to 1 and I could use that as a trigger. At the first O365 check after 8:00, sensor.herecomesthebus would reset to 0 essentially reloading it for the next trigger event.

[RogerSelwyn]

I would be more appropriate to write this with a template binary_sensor, (which as I usually say I know I could do in NodeRed, so something that is relatively straight forward like this should be able to be done in HA native). You can set the value of the sensor based on the value of attributes of another sensor.

If query sensor changes, check if date received is between X and Y today, set sensor to True, otherwise set it to False.

I'd rather you use the inbuilt capabilities of HA, rather than try and make the O365 overly complex. So my plan is to add the body_contains option when it is available in the O365 Python Module, and thank you for pointing out the bcc, I've removed that.

[GitHubGoody]

Ok, thank you. I probably don't understand the use case for the query sensors as originally intended then, but I can do this with template sensors no problem.

[RogerSelwyn]

I didn't create them.... before my time 😀. But I can see some value in winnowing down the mass of mail people may get. But with what is there (plus body), I think you will have a manageable set of data to template against.

Also you will put much less load on O365 and HA with one query sensor and many templates, rather than many query sensors.

[GitHubGoody]

Great point...although in my case I have those folders setup to sweep out all but 1-2 e-mails a day. But, I understand.

In any case, thank you for continuing to work on this. I wish I had the skills to contribute. ;-)

[RogerSelwyn]

Closed with latest release

[GitHubGoody]

Awesome! Thank you.