#Having trouble getting IMAP template searches working

1 messages · Page 1 of 1 (latest)

distant shadow
#

I've seen some posts on the HA forums from @autumn frost mentioning that you can use a IMAP search in the event_data for IMAP template sensors, but I cannot get it to work at all. I'm hoping he might see this and come around and give me a helping hand, or someone else that knows what I'm doing wrong can point me in the right direction

I've seen this mentioned a few times on the HA forums, but it doesn't work for me:

- trigger:
    - platform: event
      event_type: "imap_content"
      id: "trigger_id"
      event_data:
         search: UnSeen UnDeleted FROM "noreply@ups.com"
  sensor:
    - name: my_imap_template_sensor
      state: "{{ trigger.event.data['subject'] }}"

The line that doesn't seem to work is:
search: UnSeen UnDeleted FROM "noreply@ups.com"

I get no response from my sensor at all when I do this, just "unknown". I know there are emails that I'm matching. Ultimately, what I'm trying to do I have a bunch of emails coming from one sender, but they have different ID codes in the body. I want the latest email with the ID code "11111" to show up in sensor 1, and then the latest email from that same sender with ID code "22222" in the body to goto sensor two etc. help!

#

The way the documentation reads, the IMAP search happens on the integration configuration, not in the template script. Is it bound only to provide data from a single latest mail that matches the search configuration in the IMAP integration configuration?

If that's the case, how could I get the IMAP integration to be able to provide me info from different emails within the same mailbox?

#

I tried something like this, and sent myself an email with "7800" in the body of the email

This didn't work

- trigger:
    - platform: event
      event_type: "imap_content"
      id: "acct_test1"
      event_data:
        text: "7800"
  sensor:
    - name: acct_test1
      state: "{{ trigger.event.data['subject'] }}"  
      attributes:
        text: "{{ trigger.event.data['text']}}"
#

This does work

- trigger:
    - platform: event
      event_type: "imap_content"
      id: "acct_test1"
      event_data:
        subject: "test"
  sensor:
    - name: acct_test1
      state: "{{ trigger.event.data['subject'] }}"  
      attributes:
        text: "{{ trigger.event.data['text']}}"
#

I really dont get this its confusing....

these work

        event_data:
          sender: "my@sender.com"

        event_data:
          subject: "my subject"

but these don't work:

        event_data:
          text: "mystring"

        event_data:
          folder: "myfolder"

        event_data:
          search: ALL FROM "my@sender.com"
#

The documentation provides the following options that from what I can tell can be used in event_data

server
The IMAP server name

username
The IMAP user name

search
The IMAP search configuration

folder
The IMAP folder configuration

text
The email body text of the message (by default, only the first 2048 bytes will be available.)

sender
The sender of the message

subject
The subject of the message

date
A datetime object of the date sent

headers
The headers of the message in the for of a dictionary. The values are iterable as headers can occur more than once.

custom
Holds the result of the custom event data template. All attributes are available as a variable in the template.

autumn frost
#

When using the event_data as part of the trigger, it must match exactly... I wouldn't advise using text unless you have control of the source (i.e. you are both the sender and receiver). For that case and folder you can use the Developer Tools > Event tool to listen while you send new emails to yourself so you can see the exact values for those keys. It is quite common for folders to be shown one way in the mail client UI but appear in the event data with different capitalization.

Utilizing the IMAP search (as described in the forum post you mentioned) does require setting up multiple instances of the IMAP integration, each with it's own search criteria. This is similar to the way all IMAP Content sensors used to have to be created prior to the change to using the imap_content event.

autumn frost
# distant shadow I've seen some posts on the HA forums from <@723598229593260084> mentioning that...

For your "ID codes" question:

- trigger:
    - platform: event
      event_type: "imap_content"
      id: "trigger_id"
      event_data:
         sender: "example@domain.com"
  sensor:
    - name: my_imap_template_sensor_1
      state: |-
        {% set current = this.state | default('not set', 1) %}
        {{ trigger.event.data['subject'] if trigger.event.data['text'] is search('11111') else       
        current }}
    - name: my_imap_template_sensor_2
      state: |-
        {% set current = this.state | default('not set', 1) %}
        {{ trigger.event.data['subject'] if trigger.event.data['text'] is search('22222') else 
        current }}
distant shadow
distant shadow
#

I fell like the IMAP integration is such a powerful feature of HA, but it's either not documented well enough or it doesn't work as expected in my case...

distant shadow
#

Its just my opinion but I dont think the IMAP integration is working properly.

#

I dont think the event_data: > search: option works. It's not documented in the wiki to function that way, and i've tried it so many times and it doesn't work even with the FROM example...

autumn frost
#

Did you set up an instance of the IMAP integration with that exact search criteria? I have retested the method and it still works.

distant shadow
#

My IMAP integration has this:
IMAP search: ALL

Then my template sensor has this and it doesn't pick it up

- trigger:
    - platform: event
      event_type: "imap_content"
      id: "acct_test1"
      event_data:
        search: FROM "mysender@gmail.com"
  sensor:
    - name: acct_test1
      state: "{{ trigger.event.data['subject'] }}"  
      attributes:
        text: "{{ trigger.event.data['text']}}"
#

when I have this search: FROM line in there, it doesn't pick up any emails at all, the sensor doesn't work

autumn frost
#

Your search event data doesn't match your configured IMAP search... as explained earlier both here and the forums, they need to match

distant shadow
#

ohh sorry.

#

Why would you want to duplicate the search criteria then? If it's already in teh integration why would you need to specify it here in the trigger code?

#

or rather why would you want to do that?

#

what would be the point?

autumn frost
#

It's just an optional way to presort messages instead of using templates... some people also like to have individual IMAP sensors to use for automation triggers. For example, using the search criteria to collect emails from a specific sender or group of senders across multiple receiving accounts.

distant shadow
#

.. ohh.. so..

in theroy would this work. I setup multiple entries in my IMAP integration with different IMAP searches, and then I specify the IMAP search in the template code for each one and I would achieve different searches for different triggers?

#

Sorry if I didn't understand the explanation before

autumn frost
#

Yes...? You can set up multiple entries in the IMAP integration with each with its own IMAP search. Then you can create event triggers limited to any one of those searches. Multiple sensors can be based off a single trigger.

distant shadow
#

ahh... I am starting testing and it looks like it is working. That was not obvious to me 🙇‍♂️

#

I feel like I want to submit some change to the documentation to make this easier to understand. Maybe if it's OK with you I'll check with you with the suggestion I come up with before submitting @autumn frost ?

autumn frost
#

If you really want to, it might be worthwhile to start a Community Guide on the forums first.

distant shadow
#

Ok, I've never noticed what a community guide is. I can just search the forums for "guide" to find one? Or is there somewhat of a particular format for a community guide?

#

Thanks for your help with this. I think if there were more examples in the documentation it would be more widely adopted.

autumn frost