Struggling to get Withings integrations fully operational

Third party integrations
13

thank you, i wil try that.

14

Cannot achieve step 3 :frowning:

15

First create a Helper (Boolean) in “Device & Services” and name it something like: “Human in bed”.
Then create an automation like this:

alias: Human in bed ON
description: “”
trigger:

  • platform: webhook
    webhook_id: human_bed_on
    condition: []
    action:
  • service: input_boolean.turn_on
    data: {}
    target:
    entity_id: input_boolean.Human in bed
    mode: single

You must created one automation and webhook for ON and others for OFF. Because of IFTTT control.
Then u can place the boolean in your lovelace just to control visually and add it to Red Node/HA Automations to automate whatever u want.

16

My setup also stopped working after working before. Withings integration send the wrong URL to withings oauth. Seems it does not take the remote_URL config parameter into account anymore.

17

I think I’m seeing this too. I’ve just tried to set up a brand new Withings integration on my system. Run the wizard, it doesn’t ask me for my dev client_id, but populates it with something which Withings then reject as invalid client_id. Pasting my actual client_id from the Withings account into the URL does get me further into authorising it on Withings, but then the configuration wizard in HA just flashes back a box with Error (and no contents). Withings doesn’t get installed.

Can I see the configuration parameters for Withings in the configuration.yaml so that I can put in my settings directly without the wizard?

18

I just recently got this working (including in_bed sensor) after struggling for a bit. My set-up is completely without Nabu Casa / Home Assistant Cloud.

Steps to re-produce a working set-up:

  1. BEFORE adding the withings integration (or after removing) add the below to the configuration.yml file and restart. The integration seems to only read this config when it’s first added, not when it’s changed afterwards.

    withings:
  use_webhook: true

    See: Withings webhook for in_bed state not working · Issue #37290 · home-assistant/core · GitHub

  2. During integration set-up https://my.home-assistant.io/redirect/oauth is needed in Withings as a Callback URL to set-up the integration & authentication. The Withings website will say Partner error: Host Unreachable when you “Test” this callback. Make sure you’ve configured my.home-assistant.io to point to your external URL (duckDNS in my case).

    The set-up should be trivial after this, the re-direct will take you to my.home-assistant.io you click “Link Account” and it’ll close the tab and the integration has finished.

  3. After setting up the integration the webhook won’t be working. The trick is the following, in the file /config/.storage/core.config_entries there is now a Withings entry ("domain": "withings"). Note the following (by doing e.g. cat /config/.storage/core.config_entries from terminal):
    (a) It says "use_webhook": true (otherwise back to step 1)
    (b) It will say "webhook_id": "{UUID}" where you want to copy the {UUID} part.

  4. Go back to the Withings developer portal, add a new Callback URL using “Register Another url” and add https://{EXTERNAL_URL}/api/webhook/{UUID}. Where {EXTERNAL_URL} is the external Home Assistant URL (only accepts ports 80 or 443, for me it was XXXX.duckdns.org), and {UUID} is the UUID from step 3b. When pressing “Test” the border of the field should turn green.

  5. PROFIT!

Additional pointers should you get stuck. Enable debug logging on the Withings integration, and look for webhook related entries in the log (HELP: Received message for unregistered webhook).

18 Likes
19

This post should be included in the Withings integration’s official documentation. It solved my issues and now all the sensors receive data, including in_bed. Thanks @wilcymay !

20

Tried what @wilcymay specified above and still no go. I get a “405: method not allowed” when I put the URL in my browser from step 4, everything else works as expected though I don’t get a green success when adding the api/webhook into the Withings developer portal. I’m got the following setup in case something helps someone figure out why it’s not working for me:
Cloudflare->Nginx Proxy Manager->Home Assistant

I can reach my Home Assistant using the public domain I have for my home assistant, but adding in the /api/webhook/ gets me a 405.

Also, when I enabled the logger for my webhooks, there’s nothing in the HA logs to indicate any problems with webhooks, there’s actually nothing in the logs about webhooks even when entering in the URL from step 4.

Any ideas on what I should check?

1 Like
21

Oh my goodness!! After hours and hours searching EVERYWHERE and trial and error I found your post and IT WORKED! I don’t understand why this is not merged in the official instructions to install this integration. Thanks a lot @wilcymay !

22

I can confirm this method works and is repeatable. I set it up successfully twice, with two different withings accounts and two different sleep sensors. I am using Nabu Casa, and in my case, the callbacks still did not work until I went to settings->system->network and disabled “use home assistant cloud” under “Home Assistant URL”. I then manually pasted my Nabu Casa URL into the address box below and restarted home assistant and restarted Home Assistant. Once that was done, there were no withings or webhook related errors in the logs, and the in_bed sensors began functioning properly. Thanks @wilcymay!!

23

What kind of delay are you getting with this configuration on notifications? Specifically the in_bed.

1 Like
24

Hello,

The steps I followed are exactly the same as @wilcymay
So the summarize what i’ve done

  1. Add code to configuration.yaml
withings:
  use_webhook: true
  1. Add to Withings dev portal https://my.home-assistant.io/redirect/oauth. Set it up to point to your nabu casa instance (https://my_nabu_casa_id.ui.nabu.casa/)
  2. Go to integrations and add Withings integration and choose your user in Withings
  3. Get the UUID - can we found in setting - home assistant cloud - Webhooks
  4. Add to Withings dev portal https://my_nabu_casa_id.ui.nabu.casa/api/webhook/UUID but leave https://my.home-assistant.io/redirect/oauth in there.
  5. Went to settings->system->network and disabled “use home assistant cloud” under “Home Assistant URL”. I then manually pasted my Nabu Casa URL into the address box below
  6. Restarted home assistant

Resulting in no more errors. The reading of the bed will start once you have laid in the bed.

25

Sadly this still isn’t working for me. I am not using Nabu Casa. I just deleted it all and re-setup the integration. I set the profile name to my email address (should it be something else?). The test button turned the field green with the /api/webhook/ url.

HA is able to reach out to the API and can get the sleep data, but the in_bed sensor is still unavailable (even after laying on the bed); evidently it’s not getting the webhook data.

I get this error in the logs on reboot:

Unexpected error fetching subscription_update_coordinator data: Error code 293

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 239, in _async_refresh
    self.data = await self._async_update_data()
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 195, in _async_update_data
    return await self.update_method()
  File "/usr/src/homeassistant/homeassistant/components/withings/common.py", line 321, in async_subscribe_webhook
    return await self._do_retry(self._async_subscribe_webhook)
  File "/usr/src/homeassistant/homeassistant/components/withings/common.py", line 317, in _do_retry
    raise exception
  File "/usr/src/homeassistant/homeassistant/components/withings/common.py", line 306, in _do_retry
    return await func()
  File "/usr/src/homeassistant/homeassistant/components/withings/common.py", line 363, in _async_subscribe_webhook
    await self._hass.async_add_executor_job(
  File "/usr/local/lib/python3.10/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/local/lib/python3.10/site-packages/withings_api/__init__.py", line 348, in notify_subscribe
    self.request(path=self.PATH_NOTIFY, params=params)
  File "/usr/local/lib/python3.10/site-packages/withings_api/__init__.py", line 115, in request
    return response_body_or_raise(
  File "/usr/local/lib/python3.10/site-packages/withings_api/common.py", line 830, in response_body_or_raise
    raise InvalidParamsException(status=status)
withings_api.common.InvalidParamsException: Error code 293

Any idea?

26

I’m having the same issue. Also not using Nabu Casa for external access. It won’t even reach my domain/api/webook/UUID, but I am able to create nabu casa webhook and reach HA that way (since I still have Nabu Casa). I get that same error.

EDIT: I solved my issue. I use a Cloudflare tunnel for remote access and was blocking foreign countries accessing my HA instance. Withings webhook server was pinging from France, so I had to update my filter

28

I also use a cloudflare tunnel, what exactly did you do to unblock the other countries? I whitelisted those IP’s you get from the dig here: Keep user’s data up to date | Withings

29

My router/reverse proxy also blocks foreign countries. Allowing France is what fixed it for me.

30

I still block all countries, but allow “/api”. My rule is as follows:

  1. Country not equal US
    AND
  2. URI Path does not contain /api
    THEN Block/Managed Challenge
1 Like
31

For those still struggeling, some additional info from todays point of view:
The commands dig +short TXT ipblock-front.withings.net and dig +short TXT ipblock-notify.withings.net turned out to return empty. On reddit however I found:

dig +short TXT ipblock-front.withings.net
"89.30.121.143 89.30.121.144 89.30.121.145 89.30.121.146 89.30.121.140 89.30.121.150 89.30.121.160 89.30.121.170"
 dig +short TXT ipblock-notify.withings.net
"89.30.121.171 89.30.121.172 89.30.121.173 89.30.121.174 89.30.121.150"

This may be combined as 89.30.121.0/24, but as it turns out, I did not need any explicit IP whitelisting.

I am using duckdns. Originally, I was using the “NGINX Home Assistant SSL proxy” addon as well, but I did not manage to whitelist 89.30.121.0/24 using this add-on. Also withings only reported the 293 error or “unknown” values on the sensor. There are no options for ip or subnet whitelisting in above add-on

Digging a bit deeper, I found out that there is a much more powerful NGINX-addon available, named: Nginx Proxy Manager: GitHub - hassio-addons/addon-nginx-proxy-manager: Nginx Proxy Manager - Home Assistant Community Add-ons
So I removed the “NGINX Home Assistant SSL proxy” addon and installed " Nginx Proxy Manager" instead. I followed the installation steps provided here: addon-nginx-proxy-manager/DOCS.md at dab35df9a3b6f2df832d89d0548243b67a95c748 · hassio-addons/addon-nginx-proxy-manager · GitHub which involved installing MariaDB and additionally editing my port forward rule to include port 80:80 in addition to the 443:443 as well.

I then created a proxy hosts rule in the Proxy Manager Web Interface for Duckdns (examples are available online on how to do this). I selected “Websocket Support”, Publicly Accessible and “Force SSL” in the various tabs.

Next, I extended the trusted_proxies part in configuration.yaml to:

trusted_proxies:
    - 127.0.0.1
    - 172.30.33.0/24
    - ::1

I did not touch anything in the cors_allowed_origins field, which is set to the following for me, following an online tutorial which recommended this configuration (I was wondering if this also had a role in it, but apparently not):

cors_allowed_origins:
    - https://google.com
    - https://www.home-assistant.io

After a reboot the Withings integration worked straight away (I had already done steps 1-4 from @wilcymay before)!

So, it turned out that I did not need to actively add any whitelisting or custom proxy configuration in the proxy manager. Just the change of the add-on and the addition of above lines in configuration.yaml was sufficient. I cannot say which of the two actions made the difference now, but I suspect that it is the add-on change, where the configuration change is just a requirement for the addon to run properly.

32

@wilcymay has the solution.

Clarifying Notes:

Use the same domain in the my.home-assistant.io redirect as your callback URL in the Withings dev app.

If My Home Assistant is enabled, the setup flow always sends https://my.home-assistant.io/redirect/oauth, so you need to use it and have it set up to match your configuration in Withings Dev.

The Withings servers are reaching out to your Home Assistant server, and until they get a 200 back from their webhook request. This means if you aren’t using Nabu Casa you have to verify the withing servers are passing through your router/firewall/reverse proxy and reaching your Home Assistant server. You’ll see 6 webhook requests come through from Withings every 10 minutes or so unless you trigger a sensor.

@Jens_Wymeersch mentioned: The reading of the bed will start once you have laid in the bed.
You won’t get an In Bed detected until you trigger that sensor.
Don’t be fooled by the red Unavailable icon after completing the setup. It’s probably working.
The API returns Unavailable when ‘in bed’ is not detected for more a full check-in period. The sequence is “in bed: Detected”, “in bed: not detected”, “in bed: Unavailable. So about 10 minutes after you get out of bed, the sensor turns Unavailable but will switch back to Detected as soon as you lay day again.

1 Like
33

I found this
works a dream

1 Like