home-assistant / home-assistant.io

:blue_book: Home Assistant User documentation
https://www.home-assistant.io
Other
4.93k stars 7.26k forks source link

Correction to "Sending messages to Signal to trigger events" #30585

Closed morikplay closed 2 months ago

morikplay commented 10 months ago

Feedback

The current example for this section is misleading for 2 reasons:

- resource: "http://127.0.0.1:8080/v1/receive/<number>"
  headers:
    Content-Type: application/json
  sensor:
    - name: "Signal message received"
      value_template: "" #this will fetch the message
      json_attributes_path: $[0].envelope
      json_attributes:
        - source #using attributes you can get additional information, in this case, the phone number.
  1. value_template needs a value for json_attributes to work. It can be found on the authors' original page.
  2. Per Swagger API definitions, providing payload is mandatory for this to work. It is missing in the authors' original page example as well

Here's a working example from my testing:

  - resource: "http://homeassistant.esco.ghaar:8080/v1/receive/<number>"
    method: GET
    headers:
      Content-Type: application/json
    payload: '{"number": "<number>"}'
    sensor:
      - name: "signal chatbot"
        unique_id: <unique_id>
        value_template: "{{ value_json[0].envelope.dataMessage.message }}"         # this will fetch the msg
        json_attributes_path: $[0].envelope
        json_attributes:
          - source # this is senders' phone number, not the recipient (which is what the chat bot uses)
          - dataMessage #this contains the actual message and other useful information e.g. recipient (esp if group)

URL

https://www.home-assistant.io/integrations/signal_messenger/

Version

2023.12.4

Additional information

No response

home-assistant[bot] commented 10 months ago

Hey there @bbernhard, mind taking a look at this feedback as it has been labeled with an integration (signal_messenger) you are listed as a code owner for? Thanks!

Code owner commands Code owners of `signal_messenger` can trigger bot actions by commenting: - `@home-assistant close` Closes the feedback. - `@home-assistant rename Awesome new title` Renames the feedback. - `@home-assistant reopen` Reopen the feedback. - `@home-assistant unassign signal_messenger` Removes the current integration label and assignees on the feedback, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information) to the feedback. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information) on the feedback.
renini commented 9 months ago

@morikplay i am getting, the following: Template variable error: list object has no element 0 when rendering '{{ value_json[0].envelope.dataMessage.message | default('', true) }}'

Probably because there is no new messages and no array returned. But not sure if this was visible before HA version 2024.1.2.

But by the way, i don't see the mandatory payload in the swagger api documentation for the GET v1/receive endpoint, and you are already passing the number in the URI. Isn't payload only for POST endpoints anyways?

morikplay commented 9 months ago

@renini Thank you so much for looking into the issue and responding.

@morikplay i am getting, the following: Template variable error: list object has no element 0 when rendering '{{ value_json[0].envelope.dataMessage.message | default('', true) }}' Probably because there is no new messages and no array returned. But not sure if this was visible before HA version 2024.1.2.

If receive response returns nothing (meaning nothing left to retrieve from signal server) then obviously there won't be any payload to evaluate. I'm sure my configuration could be cleaned up using templates, but being rather new to REST APIs, I did try to keep things simple. I can change the value_template to:

        value_template: >-
          {% value_json != none and value_json | length >  0 %}
            {{ value_json[0].envelope.dataMessage.message }}
          {% endif %}

But by the way, i don't see the mandatory payload in the swagger api documentation for the GET v1/receive endpoint, and you are already passing the number in the URI. Isn't payload only for POST endpoints anyways?

Per Swagger API, {number} is mandatory. Obviously it is mandatory because the REST URI needs to be formulated. However, when testing in insomnia i noticed that:

  1. If no payload is included, nothing is returned even though there are pending messages to be received. A message log (for a msg sent by {no1} to a group containing {no1, no2, no3} with group-owner being no3 can be seen below:
    REQUEST: GET URI: http://<my-signal-container-instance-address>/v1/receive/{no3}
    RESPONSE: []
  2. If payload per above, which has the same number: {number} included returns data. A message log (for a msg sent by {no1} to a group containing {no1, no2, no3} with group-owner being no3 can be seen below:
    REQUEST: GET URI: http://<my-signal-container-instance-address>/v1/receive/{no3}
    {
    "number": "{no3}",
    max_messages: "1"
    } 
    RESPONSE: [
    {
        "envelope": {
            "source": "{no1}",
            "sourceNumber": "{no1}",
            "sourceUuid": "{no1_uuid}",
            "sourceName": "{name}",
            "sourceDevice": {n},
            "timestamp": 1703993110672,
            "dataMessage": {
                "timestamp": 1703993110672,
                "message": "test",
                "expiresInSeconds": 0,
                "viewOnce": false,
                "groupInfo": {
                    "groupId": "{group1}",
                    "type": "DELIVER"
                }
            }
        },
        "account": "{no3}"
    }
    ]

Are you suspecting funky behavior specific to my settings only?

github-actions[bot] commented 7 months ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved. If this issue is still relevant, please let us know by leaving a comment 👍 This issue has now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.