Actionable notifications stop working in 0.83.1

[mihauu1983]

Home Assistant release with the issue:

Last working Home Assistant release (if known):
0.82.1

Operating environment (Hass.io/Docker/Windows/etc.):

Component/platform:
ios push

Description of problem:

My actionable notifications worked perfectly, but after upgrading into 0.83.0 and 0.83.1 notifications are still delivered but respond is not working.

It prompts:
Login attempt or request with invalid authentication from 192.168.1.1

[ahayworth]

What version of the iOS app are you running? You might want try upgrading to the beta 1.5.0 release - there have been authentication fixes that might apply to you: https://community.home-assistant.io/t/public-beta-testing-is-now-open/70450

[deluxestyle]

I have the same issue with the current (not beta) version of the iOS App

[deluxestyle]

tried it with the latest beta version but still same issue

[welbo97]

Just my luck, I tried to create a new actionable notification with the ios app for the first time on 83.1. I've been chasing my tail for a week trying to figure out why the app gets an authentication error on the response.
IOW, same problem here...

[alon-z]

Using the latest beta:
The devices sends a correct POST request:

POST /api/events/ios.notification_action_fired HTTP/1.1
Host: XXX.XXX.XXX.abc:8123
Content-Type: application/json
Connection: keep-alive
X-HA-Access: MYCODE
Accept: /
User-Agent: Home Assistant/1.5.0 (io.robbie.HomeAssistant; build:31; iOS 12.0.1) Alamofire/4.7.3
Accept-Language: en-IL;q=1.0, he-IL;q=0.9, ja-JP;q=0.8
Accept-Encoding: gzip;q=1.0, compress;q=0.5
Content-Length: 150
{"actionName":"STOP_ALARM","sourceDevicePermanentID":"XXX-XXXX-XXX","sourceDeviceID":"myiphone","sourceDeviceName":"MyiPhone"}

Getting back:

HTTP/1.1 401 Unauthorized

homeassistant:
  auth_providers:
    - type: homeassistant
    - type: legacy_api_password
    - type: trusted_networks
http:
  api_password: MYCODE
  trusted_networks:
    - XXX.XXX.XXX.myiphone
    - XXX.XXX.XXX.0/24
  ip_ban_enabled: false

[deluxestyle]

is someone looking into that issue? still not solved.

[mlowijs]

I have the same issue on 0.84 with the beta app. Tried with legacy API password and with new HA authentication.

[Fonta]

I seem to somehow have been able to fix this.
What I did was disabling the legacy API password completely and after that logging off and logging back into the app (ofcourse after restarting HA).

This is what I have now in my config:

In the app itself I've also turned off the slider for "Use legacy authentication".

Edit:
I just remembered that I also deleted the legacy user using HA under Configuration -> Users.

Simply said, I've just removed everything that has to do with the legacy API password.

[deluxestyle]

thank you
this helps

[mlowijs]

I disabled legacy auth too, maybe need to remove the api_password property as well. Will test later.

…

Sent from my iPhone

On 23 Dec 2018, at 16:43, deluxestyle ***@***.***> wrote: thank you this helps — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[deluxestyle]

yes you need. see the screenshot. there it is commented out

[Fonta]

I've added an extra line to the post about also removing the legacy api user. I just remembered doing so.
In the end I'm not sure what exactly did the trick for me. But the result is working actionable notifications and being completely free of anything to do with the legacy API password.

[Fonta]

Been digging some more in the documentation.
It doesn't seem to be necessary to set the auth providers.
That's because the homeassistant provider gets enabled by default.
Configuring an api_password in the http: section doesn't make the legacy_api_password auth provider load.
Simply removing the api_password setting from http: should therefor be enough to fix the issue.
I've also tested this by removing the auth_providers: section from homeassistant: and restarting HA.
Everything still works.

[mlowijs]

@f0nt4 Seems to work to remove the auth_provider and api_password!

[partytimeexcellent]

I have just setup my first actionable notifications on a fresh install of HS 87.1 and never configured any legacy API or auth_provider in the config, so that should not be an issue here. I cannot get any actions to trigger based on the event bus seeing the "ios.notification_action_fired" event.

When I click the button on my actionable notification, I get the following in the event bus:

[homeassistant.core] Bus:Handling <Event ios.notification_action_fired[R]: actionName=YES, sourceDeviceID=iphonex, sourceDevicePermanentID=removed, sourceDeviceName=iPhoneX>

which should trigger this automation:

  - alias: Reset Actionable Boolean
    initial_state: True
    trigger:
      platform: event
      event_type: ios.notification_action_fired
      event_data:
        actionName: YES
    action:
      service: input_boolean.turn_off
      entity_id: input_boolean.actionable_test

However, nothing further appear in the logs and the automation doesn't fire. Anyone experiencing this or see anything wrong with my code?

[h4nc]

The top level identifier needs to be lower case letters only.

The action identifier has to be upper case letters only.
This was my issue when I set up actionable notifications.

[partytimeexcellent]

I solved this. Turns out the 'event_data' field needs to be formatted differently than the documentation page suggests. This is what works for me:

  trigger:
    - platform: event
      event_type: 'ios.notification_action_fired'
      event_data: {'actionName': 'YES'}

I put in a pul request to have the docs updated.

[h4nc]

Mine works in this format:

  trigger:
    platform: event
    event_type: ios.notification_action_fired
    event_data:
      actionName: YES

So exatly like your example above. Only Thing I changes is the action name from mine to YES.
Don't know if it's necessary to change the docs.

[ghost]

This issue was moved by robbiet480 to home-assistant/home-assistant-iOS#226.

[ghost]

This issue was moved by robbiet480 to home-assistant/home-assistant-iOS#227.