Upgrade needed

[wojta95]

Hi,

Node Red now won't let you install this addon and shows the following request for it to be updated: npm WARN deprecated node-webcrypto-ossl@1.0.49: node-webcrypto-ossl has been deprecated. This module was created in 2015 because at the time the Node team did not feel the need to have two crypto interfaces and they already had one before WebCrypto was defined npm WARN deprecated core-js@2.6.12: core-js@<3.3 is no longer maintained and not recommended for usage due to the number of issues. Because of the V8 engine whims, feature detection in old core-js versions could cause a slowdown up to 100x even if nothing is polyfilled. Please, upgrade your dependencies to the actual version of core-js. npm ERR! code 1 npm ERR! path /config/node-red/node_modules/utf-8-validate npm ERR! command failed npm ERR! command sh -c node-gyp-build npm ERR! gyp info it worked if it ends with ok npm ERR! gyp info using node-gyp@7.1.2 npm ERR! gyp info using node@14.18.1 | linux | arm64 npm ERR! gyp info find Python using Python version 3.9.5 found at "/usr/bin/python3" npm ERR! gyp info spawn /usr/bin/python...

[dannykorpan]

Same problem

[datacyclist]

Same issue here.

[achim-guldner]

And for me, but as this was last maintained over 9 months ago, is there a chance it will get updated?

[NaruZosa]

It seems unlikely. How likely is it that it'll be updated @gausma ?

[odiseo123]

Same issue. Did others find a work around?

[wojta95]

No, I haven't :/

[odiseo123]

I managed to work around using a restful sensor.

First try it in the terminal to see if it is working:

curl -X GET -H "Content-Type: application/json" 'http://IP:8080/v1/receive/+123456789'

The IP/Port is the IP of the device running the Signal add-on, +123456789 is the phone number associated to your signal messenger. If you have already managed to register the number and receive notifications, the above GET request should work out of the box as it is supported by the API (https://bbernhard.github.io/signal-cli-rest-api/#/Messages/get_v1_receive__number_). When you send a message from the Signal app, it will be marked with a single check-mark (i.e 'sent'). Then you issue the above command in the Hassio terminal. You should get a reply like:

[{"envelope":{"source":"+12345678","sourceDevice":1,"timestamp":1647696532681,"dataMessage":{"timestamp":1647696532681,"message":"Test","expiresInSeconds":0,"viewOnce":false,"mentions":[],"attachments":[],"contacts":[]}}}]

The reply can take up to a minute in the default mode ('normal'?, aka native_mode = 0). I read somewhere than using 'json-rpc' mode should be much faster. However, GET requests are not supported in 'json-rpc' mode. One would have to use 'wscat', which was not supported by my HASSIO instance. Anyway, once the the message is read in the terminal, the message in the Signal should get a second tick (e.g. 'read').

If the above works, then that is half of the nightmare over... you are receiving Signal messages in Hassio.

Now to make that useful, you can create a RESTful sensor that strips and stores the useful bits of information from the whole message. Note the reply is an array of messages (i.e. reply in square brackets). If you have several unread messages, your GET request will return an array with several "envelope" objects. If there are no unread messages, you get an empty array '[]'.

In my case, I am assuming I will get a single envelope request, so I only care about the first "envelope" object in the array, see [0] below. I point the attribute path to dataMessage which contains the two attributes of interest to me: the actual text message and the timestamp.

sensor:
# Signal messenger receiver
  - platform: rest
    resource: http://IP:8080/v1/receive/+12345678
    method: GET
    name: Signal_Command
    json_attributes_path: "$.[0].envelope.dataMessage"
    json_attributes:
      - message
      - timestamp
    scan_interval: 60
    timeout: 59

I tweaked the scan_interval and timeout. As I mentioned, messages can take up to a minute to be fetched from the server. I think the default timeout is 10 seconds, so definitely make sure to adjust that value based on your reply delay. The scan interval is basically the polling time.

Now you can use the above in automations and/or with templating:

{{ states('sensor.signal_command') }}  # Gives you the full array of envelopes
{{ state_attr('sensor.signal_command', 'message') }}  # Gives you the message in the first envelope element

From here you can compare the 'message' attribute with a desired value and execute actions accordingly. For instance, I use a template to compare against a string 'panic' (case insensitive) to trigger the burglar alarm:

  - binary_sensor:
      - name: Remote_Panic
        state: >
            {% if state_attr('sensor.signal_command', 'message') is match("panic", ignorecase=True) %}
                true
            {% else %}
                false
            {% endif %}

I hope the above helps. I am yet to document the above in my notes, so excuse the mess. I spent hours finding the above workaround, so the tidy-up will have to wait for another weekend.