jcgoette / baby_buddy_homeassistant

This custom integration provides sensors for Baby Buddy API endpoints.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Services stopped working with latest update

sfgabe opened this issue · comments

commented

I updated baby buddy and home assistant at the same time so I'm not sure which one is the culprit, but services stopped working as of the 1 April home assistant update.

Happen to anyone else? Any ideas what it could be?

Any errors in log?

commented

None that I can see.

commented

Correction- I noticed there was no associated child and tried to add one. Here is the error from that:

aiohttp.client_exceptions.ContentTypeError: 0, message='Attempt to decode JSON with unexpected mimetype: text/plain; charset=utf-8', url=URL('https://www.url.com/api/children/')

commented

I think the issue may be that it does not seem to add the port in the API call

Seems unlikely. Unless something with your BB host/port also changed?

commented

I was previously using the local dns but that won't even get a response now (though it works from a browser) so I removed the integration and added it as the external url. That one can be added but does not receive data or make service calls without this error.

Here's the full error:

`This error originated from a custom integration.

Logger: homeassistant.helpers.script.websocket_api_script
Source: custom_components/babybuddy/client.py:64
Integration: Baby Buddy (documentation, issues)
First occurred: April 9, 2022, 9:40:06 PM (6 occurrences)
Last logged: 1:28:09 AM

websocket_api script: Error executing script. Unexpected error for call_service at pos 1: 0, message='Attempt to decode JSON with unexpected mimetype: text/plain; charset=utf-8', url=URL('https://www.url.com/api/children/')
websocket_api script: Error executing script. Unexpected error for call_service at pos 1: 0, message='Attempt to decode JSON with unexpected mimetype: text/html', url=URL('http://www.url.com/api/children/')
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 379, in _async_step
await getattr(self, handler)()
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 582, in _async_call_service_step
await service_task
File "/usr/src/homeassistant/homeassistant/core.py", line 1634, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1671, in _execute_service
await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)(
File "/config/custom_components/babybuddy/init.py", line 178, in async_add_child
await self.client.async_post(ATTR_CHILDREN, data)
File "/config/custom_components/babybuddy/client.py", line 64, in async_post
error = await resp.json()
File "/usr/local/lib/python3.9/site-packages/aiohttp/client_reqrep.py", line 1103, in json
raise ContentTypeError(
aiohttp.client_exceptions.ContentTypeError: 0, message='Attempt to decode JSON with unexpected mimetype: text/plain; charset=utf-8', url=URL('https://www.url.com/api/children/')
`

This is starting to sound like this.

Are you familiar with editing the code in your own HA instance?

commented

It looks like its related to the new CSRF_TRUSTED_ORIGINS requirement that I think others have had problems with. I needed to add both external and local urls and now I can access both separately. Ive reinstalled the add on but its still not recognizing either of those instances through Home Assistant.

Are you familiar with editing the code in your own HA instance? If so, could you edit this, restart Home Assistant, and attempt workflow again?

From error = await resp.json()
To error = await resp.json(content_type=None)

commented

I made that code change and I'm not sure if it made a difference. I can't seem to get it to recognize the existing child that's in there. Any ideas?

commented

`This error originated from a custom integration.

Logger: homeassistant.helpers.script.websocket_api_script
Source: custom_components/babybuddy/client.py:64
Integration: Baby Buddy (documentation, issues)
First occurred: 11:09:33 PM (1 occurrences)
Last logged: 11:09:33 PM

websocket_api script: Error executing script. Unexpected error for call_service at pos 1: Expecting value: line 1 column 1 (char 0)
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 379, in _async_step
await getattr(self, handler)()
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 582, in _async_call_service_step
await service_task
File "/usr/src/homeassistant/homeassistant/core.py", line 1634, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1671, in _execute_service
await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)(
File "/config/custom_components/babybuddy/init.py", line 178, in async_add_child
await self.client.async_post(ATTR_CHILDREN, data)
File "/config/custom_components/babybuddy/client.py", line 64, in async_post
error = await resp.json(content_type=None)
File "/usr/local/lib/python3.9/site-packages/aiohttp/client_reqrep.py", line 1119, in json
return loads(stripped.decode(encoding))
File "/usr/local/lib/python3.9/json/init.py", line 346, in loads
return _default_decoder.decode(s)
File "/usr/local/lib/python3.9/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/local/lib/python3.9/json/decoder.py", line 355, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
`

Hmm. Can you try changing to resp.text()?

commented

OK. Where is that?

Same line as before.

From error = await resp.json()
To error = await resp.text()

commented

I made that change and tried to recreate child - got a 404 error in every language! 🤣

This error originated from a custom integration.

Logger: custom_components.babybuddy.client
Source: custom_components/babybuddy/client.py:65
Integration: Baby Buddy (documentation, issues)
First occurred: 9:13:56 PM (1 occurrences)
Last logged: 9:13:56 PM

Could not create children. error: <!DOCTYPE html> <html> <head> <meta charset="utf-8"> <style>.center{font-family:Verdana,Arial,sans-serif}.center:lang(zh-TW){font-family:Verdana,Arial,Microsoft JhengHei,sans-serif}.center:lang(zh-CN){font-family:Verdana,Arial,Microsoft YaHei,sans-serif}.center:lang(ja){font-family:Verdana,Arial,Meiryo,sans-serif}.circle_text{font-weight:700}html{height:100%}body{margin:0 auto;min-height:600px;min-width:800px;height:100%}.top{height:100px;height:calc(40% - 140px)}.bottom{height:150px;height:calc(60% - 210px)}.center{height:350px;text-align:center;vertical-align:middle}.circle{margin:auto;width:260px;height:260px;border-radius:50%;background:#c0c6cc}.circle_text{line-height:260px;font-size:100px;color:#fff}.text{line-height:40px;font-size:26px;color:#414b55} </style> </head> <body> <div class="top"></div> <div class="center"> <div class="circle"> <div class="circle_text">404</div> </div> <div> <p class="text" id="a"></p> </div> <script> /* Copyright (c) 2021 Synology Inc. All rights reserved. */ (function(){var a=new XMLHttpRequest();a.open("get","/missing",true);a.send();a.onreadystatechange=function(){if(a.readyState==4&&(a.status==200||a.status==304)){var c=String(a.responseText);var e=document.open("text/html","replace");e.write(c);e.close()}else{var d={en:"The page you are looking for cannot be found.",zh:"\u60a8\u8981\u627e\u7684\u9875\u9762\u672a\u627e\u5230\u3002",it:"Impossibile trovare la pagina ricercata.","zh-HK":"\u60a8\u6240\u6307\u5b9a\u7684\u9801\u9762\u4e0d\u5b58\u5728\u3002",cs:"Hledan\u00e1 str\u00e1nka nebyla nalezena.",es:"Lo sentimos, no se encuentra la p\u00e1gina que est\u00e1 buscando.",ru:"\u041d\u0435 \u0443\u0434\u0430\u0435\u0442\u0441\u044f \u043d\u0430\u0439\u0442\u0438 \u0438\u0441\u043a\u043e\u043c\u0443\u044e \u0441\u0442\u0440\u0430\u043d\u0438\u0446\u0443.",nl:"Kan de gezochte pagina niet vinden.",pt:"A p\u00e1gina que procura n\u00e3o foi encontrada.",no:"Finner ikke siden du leter etter.",nb:"Finner ikke siden du leter etter.",tr:"Arad\u0131\u011f\u0131n\u0131z sayfa bulunam\u0131yor.",pl:"Nie znaleziono strony, kt\u00f3rej szukasz.",fr:"La page que vous recherchez est introuvable.",de:"Die Seite, nach der Sie suchen, kann nicht gefunden werden.",hu:"A keresett oldal nem tal\u00e1lhat\u00f3.","pt-BR":"N\u00e3o foi poss\u00edvel encontrar a p\u00e1gina que voc\u00ea est\u00e1 buscando.","zh-MO":"\u60a8\u6240\u6307\u5b9a\u7684\u9801\u9762\u4e0d\u5b58\u5728\u3002",da:"Den side, du leder efter, kunne ikke findes.",ja:"\u304a\u63a2\u3057\u306e\u30da\u30fc\u30b8\u304c\u3001\u898b\u3064\u304b\u308a\u307e\u305b\u3093\u3002",nn:"Finner ikke siden du leter etter.","zh-TW":"\u60a8\u6240\u6307\u5b9a\u7684\u9801\u9762\u4e0d\u5b58\u5728\u3002",ko:"\ucc3e\uace0 \uacc4\uc2e0 \ud398\uc774\uc9c0\ub97c \ubc1c\uacac\ud560 \uc218 \uc5c6\uc2b5\ub2c8\ub2e4.",sv:"Sidan du s\u00f6ker kunde inte hittas."};var b=["zh-TW","zh-HK","zh-MO","pt-BR"];var f;if(window.navigator.languages!==undefined){f=window.navigator.languages[0]}else{f=window.navigator.language||window.navigator.browserLanguage}if(b.indexOf(f)<0){f=f.split("-")[0]}document.getElementById("a").innerHTML=d[f]||d.enu}}})(); </script> </div> <div class="bottom"></div> </body> </html>

That's funny. Not sure how much it helps.

Does this part mean anything to you?

Copyright (c) 2021 Synology Inc. All rights reserved.

commented

Yes. Both baby buddy and home assistant are running in a Docker container on a Synology NAS. It appears to be a generic Synology 404 page, but I don't get that when I am accessing the api url directly.

commented

I'm messing with the baby buddy settings and I think I might be getting closer. I think there was a problem with my setup as far as the new CSRF_ORIGINS setting, but also now that I think I've gotten around that, I'm getting this

This error originated from a custom integration.

Logger: custom_components.babybuddy
Source: custom_components/babybuddy/__init__.py:134
Integration: Baby Buddy (documentation, issues)
First occurred: 1:18:40 AM (29 occurrences)
Last logged: 1:46:40 AM

Unexpected error fetching babybuddy data: 'count'
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 190, in _async_refresh
    self.data = await self._async_update_data()
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 150, in _async_update_data
    return await self.update_method()
  File "/config/custom_components/babybuddy/__init__.py", line 134, in async_update
    if children_list[ATTR_COUNT] == 0:
KeyError: 'count'
commented

I rolled back to BabyBuddy 1.9.3 and removed the new CSRF_ORIGINS settings and it works fine as before - that version is fine for my use case. I assume it's something related to docker settings and babybuddy/babybuddy#393 but I can't spend more time with it while keeping track of the new kiddo. 😄 Thank you for the help!

Updated HA last night and ran into the same issue as @sfgabe. Rolled back HAOSS to before the april update and still had the issue. Changed the version of my BabyBuddy docker container and removed CSRF_ORIGIN env variable and now it works...

Yeah I have no sensors available in HA - only my select.

HA is complaining of Unable to find referenced entities sensor.baby_baby_name

I'm guessing all of you are using NGINX as a reverse proxy?

I do, however my HA is talking to baby buddy locally and I'm accessing both locally.

I have Swag setup to access HA outside the network, but HA integration is accessing BB locally through my IP, not my domain. All aspects of BB were 'unavailable' in HA. However, I do have a few REST items in the config pulling information (how many diaper changes in a day) and that was working, but that is NOT from the BB integration.

commented

I have a similar setup to @Borlean where I'm using nginx, and have an outside https domain for BB but was accessing it through home assistant via the http local ip. I tried using the outside domain as well and no luck there either.

The only thing I can add at this point is: if your nginx.conf has the line proxy_pass in it for BB, check your proxy_set_header settings in nginx.conf. I am using latest HA and latest BB image and all works for me.

My nginx.conf file for BB does NOT have the proxy_pass line. It's the 2021/10/24 version, is yours newer? I don't even see a proxy_set_header option.

Confirmed that my setup works with the latest HA (core-2022.4.5) and BB 1.9.3.

It stopped working on my installation as well.
What I can see is this in the logs after setting up the integration:

Source: helpers/update_coordinator.py:222
Integration: Baby Buddy ([documentation](https://github.com/jcgoette/baby_buddy_homeassistant), [issues](https://github.com/jcgoette/baby_buddy_homeassistant/issues))
First occurred: 07:32:49 (2 occurrences)
Last logged: 07:39:05

Error fetching babybuddy data: Cannot connect to host 192.168.200.2:80 ssl:default [Connect call failed ('192.168.200.2', 80)]

It seems it tries to connect on port 80 but I have set up the integration on a different port.
This looks odd to me.

@myxor looks like you left off the http or https when setting up.

@jcgoette

I re-setup the integration now multiple times with http:// and also https:// (i am using Nginx proxy) but the error messages stays the same no matter which port i type in:

Error fetching babybuddy data: Cannot connect to host 192.168.200.2:80 ssl:default [Connect call failed ('192.168.200.2', 80)]

If i type in a wrong port the setup of the integration does not work of course. So i type in the correct port and setup confirms it with a success message. Right after that i see the above error in the log where the port is set to 80 again.

EDIT: I found the configuration JSON .storage/core.config_entries and it says:

"data": {
               "host": "https://192.168.200.2",
               "port": 8127,
               "api_key": "0ef2516xxxxxx"
           }

Did you obfuscate and truncate your API key? Because if not, it looks like not enough characters.

Checking that you've set to this integration successfully before?

Did you obfuscate and truncate your API key? Because if not, it looks like not enough characters.

Yes i did. Sorry - i should have pointed that out.

Checking that you've set to this integration successfully before?

It was working around one week ago for sure. Meanwhile i updated HA to 2022.4.6 and BB to v1.10.2.

Collecting more data: what is your setup like? Docker? Local or hosted HA and BB? NGINX? If so, would you (or anyone else on this thread) be willing to share your nginx.conf?

My setup:

  • HA and BB in docker container
  • Nginx in docker dontainer as reverse proxy

Nginx config part:

Note: [my external server name] is my DNS of the server.

# Baby Buddy
server {
     listen 8127 ssl;
     server_name [my external server name];
     ssl_certificate /etc/letsencrypt/live/[my external server name]/fullchain.pem;
     ssl_certificate_key /etc/letsencrypt/live/[my external server name]/privkey.pem;

     location / {
          proxy_pass http://192.168.200.2:8027;
          proxy_set_header X-Forwarded-For $remote_addr;
      }
  }

So i am trying to setup the integration with either
http://192.168.200.2:8027 or https://[my external server name]:8127 and i also tried https://192.168.200.2:8127.

I can access BB with all three of the above addresses via browser while the last one having a SSL certificate not matching the address.

My configuration is HAOS on VM, Babybuddy and NGINX proxy manager running in docker in another VM, different IP addresses. Baby buddy accessible normally either via internal or external access. Configured baby buddy using the local IP address rather than external domain

I'm not an expert, but this looks strange to me. I would expect:

  • listen line to be 443 if you are using SSL
  • proxy_pass to be http://127.0.0.1:8027;

Beyond that, I can provide some additional changes to try:

http {

    # Connection header for WebSocket reverse proxy
    map $http_upgrade $connection_upgrade {
        default upgrade;
        "" close;
    }

    map $remote_addr $proxy_forwarded_elem {
        # IPv4 addresses can be sent as-is
        ~^[0-9.]+$ "for=$remote_addr";

        # IPv6 addresses need to be bracketed and quoted
        ~^[0-9A-Fa-f:.]+$ "for=\"[$remote_addr]\"";

        # Unix domain socket names cannot be represented in RFC 7239 syntax
        default "for=unknown";
    }

    map $http_forwarded $proxy_add_forwarded {
        # If the incoming Forwarded header is syntactically valid, append to it
        "~^(,[ \\t]*)*([!#$%&'*+.^_`|~0-9A-Za-z-]+=([!#$%&'*+.^_`|~0-9A-Za-z-]+|\"([\\t \\x21\\x23-\\x5B\\x5D-\\x7E\\x80-\\xFF]|\\\\[\\t \\x21-\\x7E\\x80-\\xFF])*\"))?(;([!#$%&'*+.^_`|~0-9A-Za-z-]+=([!#$%&'*+.^_`|~0-9A-Za-z-]+|\"([\\t \\x21\\x23-\\x5B\\x5D-\\x7E\\x80-\\xFF]|\\\\[\\t \\x21-\\x7E\\x80-\\xFF])*\"))?)*([ \\t]*,([ \\t]*([!#$%&'*+.^_`|~0-9A-Za-z-]+=([!#$%&'*+.^_`|~0-9A-Za-z-]+|\"([\\t \\x21\\x23-\\x5B\\x5D-\\x7E\\x80-\\xFF]|\\\\[\\t \\x21-\\x7E\\x80-\\xFF])*\"))?(;([!#$%&'*+.^_`|~0-9A-Za-z-]+=([!#$%&'*+.^_`|~0-9A-Za-z-]+|\"([\\t \\x21\\x23-\\x5B\\x5D-\\x7E\\x80-\\xFF]|\\\\[\\t \\x21-\\x7E\\x80-\\xFF])*\"))?)*)?)*$" "$http_forwarded, $proxy_forwarded_elem";

        # Otherwise, replace it
        default "$proxy_forwarded_elem";
    }
	
	# Baby Buddy
    server {
        listen 443 ssl;
        server_name [my external server name];

        # SSL
		ssl_certificate /etc/letsencrypt/live/[my external server name]/fullchain.pem;
		ssl_certificate_key /etc/letsencrypt/live/[my external server name]/privkey.pem;

        location / {
            proxy_pass http://127.0.0.1:8027;
            proxy_http_version 1.1;
            proxy_cache_bypass $http_upgrade;

            # Proxy headers
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header Forwarded $proxy_add_forwarded;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Forwarded-Host $host;
            proxy_set_header X-Forwarded-Port $server_port;
        }
    }
}

I'm not an expert, but this looks strange to me. I would expect:
listen line to be 443 if you are using SSL
proxy_pass to be http://127.0.0.1:8027;

I am using non-default SSL port and having multiple network interfaces - therefore the port and IP.

after adding your suggestions to my nginx config i am now getting an actual python error:

Unexpected error fetching babybuddy data: 'count'

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 190, in _async_refresh
    self.data = await self._async_update_data()
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 150, in _async_update_data
    return await self.update_method()
  File "/config/custom_components/babybuddy/__init__.py", line 134, in async_update
    if children_list[ATTR_COUNT] == 0:
KeyError: 'count'

Progress! :)

I have one child set up on my BB installation.

Btw: @jcgoette thx for your help!

I added some hopefully helpful debug-level logging in v2.4.1 if anyone wants to upgrade and enable debug-level logging.

# Example configuration.yaml entry
logger:
  default: info
  logs:
    custom_components.babybuddy: debug

Debug log:

2022-04-23 12:19:53 DEBUG (MainThread) [custom_components.babybuddy.client] Client API Token: 0ef2516c6 [truncated by me]
2022-04-23 12:19:53 DEBUG (MainThread) [custom_components.babybuddy.client] Client URL: http://192.168.200.2:8027
2022-04-23 12:19:53 DEBUG (MainThread) [custom_components.babybuddy.client] GET URL: http://192.168.200.2:8027/api/
2022-04-23 12:20:23 DEBUG (MainThread) [custom_components.babybuddy.client] GET response: {"children":"http://192.168.200.2/api/children/","changes":"http://192.168.200.2/api/changes/","feedings":"http://192.168.200.2/api/feedings/","notes":"http://192.168.200.2/api/notes/","sleep":"http://192.168.200.2/api/sleep/","temperature":"http://192.168.200.2/api/temperature/","timers":"http://192.168.200.2/api/timers/","tummy-times":"http://192.168.200.2/api/tummy-times/","weight":"http://192.168.200.2/api/weight/","height":"http://192.168.200.2/api/height/","head-circumference":"http://192.168.200.2/api/head-circumference/","bmi":"http://192.168.200.2/api/bmi/"}
2022-04-23 12:20:23 DEBUG (MainThread) [custom_components.babybuddy.client] Endpoints: {'children': 'http://192.168.200.2/api/children/', 'changes': 'http://192.168.200.2/api/changes/', 'feedings': 'http://192.168.200.2/api/feedings/', 'notes': 'http://192.168.200.2/api/notes/', 'sleep': 'http://192.168.200.2/api/sleep/', 'temperature': 'http://192.168.200.2/api/temperature/', 'timers': 'http://192.168.200.2/api/timers/', 'tummy-times': 'http://192.168.200.2/api/tummy-times/', 'weight': 'http://192.168.200.2/api/weight/', 'height': 'http://192.168.200.2/api/height/', 'head-circumference': 'http://192.168.200.2/api/head-circumference/', 'bmi': 'http://192.168.200.2/api/bmi/'}
2022-04-23 12:20:23 DEBUG (MainThread) [custom_components.babybuddy.client] GET URL: http://192.168.200.2/api/children/
2022-04-23 12:20:27 ERROR (MainThread) [custom_components.babybuddy] Error fetching babybuddy data: Cannot connect to host 192.168.200.2:80 ssl:default [Connect call failed ('192.168.200.2', 80)]
2022-04-23 12:20:27 DEBUG (MainThread) [custom_components.babybuddy] Finished fetching babybuddy data in 4.479 seconds (success: False)

Looks like the port is missing in the API endpoint list response JSON as i pointed out here: babybuddy/babybuddy#446

I think you're right. My debug log pulls a HTML page of my pihole server, which is of course on port 80. Will post logs when I can get to a PC

I'm confused, haven't the proposed solutions so far been to open port 80 on the Baby Buddy server? That may be a workaround, but the bug is with the HACS integration using port 80 when it should be something else (typically 8000). How do we fix that?

All current signs point to an issue with reverse proxy setup. Your own debug logs show the host:port correctly until it hits /api/ endpoints, which is on the BB/Django side of things:

2022-04-23 08:29:29 DEBUG (MainThread) [custom_components.babybuddy.client] GET URL: http://babybuddy:8000/api/
2022-04-23 08:29:29 DEBUG (MainThread) [custom_components.babybuddy.client] GET response: {"children":"http://babybuddy/api/children/","changes":"http://babybuddy/api/changes/","feedings":"http://babybuddy/api/feedings/","notes":"http://babybuddy/api/notes/","sleep":"http://babybuddy/api/sleep/","temperature":"http://babybuddy/api/temperature/","timers":"http://babybuddy/api/timers/","tummy-times":"http://babybuddy/api/tummy-times/","weight":"http://babybuddy/api/weight/","height":"http://babybuddy/api/height/","head-circumference":"http://babybuddy/api/head-circumference/","bmi":"http://babybuddy/api/bmi/"}
2022-04-23 08:29:29 DEBUG (MainThread) [custom_components.babybuddy.client] Endpoints: {'children': 'http://babybuddy/api/children/', 'changes': 'http://babybuddy/api/changes/', 'feedings': 'http://babybuddy/api/feedings/', 'notes': 'http://babybuddy/api/notes/', 'sleep': 'http://babybuddy/api/sleep/', 'temperature': 'http://babybuddy/api/temperature/', 'timers': 'http://babybuddy/api/timers/', 'tummy-times': 'http://babybuddy/api/tummy-times/', 'weight': 'http://babybuddy/api/weight/', 'height': 'http://babybuddy/api/height/', 'head-circumference': 'http://babybuddy/api/head-circumference/', 'bmi': 'http://babybuddy/api/bmi/'}

I'm also confused - I'm not sure how the reverse proxy comes into it as the reverse proxy doesn't have anything to do with the link between HA BB integration and the BB server (all my internal things talk via local IP, nothing goes out of the network)

I could test by stopping my NGINX container, but I'm not sure that would do anything ( don't get me wrong, I know very little about API's etc, so I could be wrong.

My logs attached

2022-04-24 10:40:24 ERROR (MainThread) [custom_components.babybuddy] Unexpected error fetching babybuddy data: 'count'
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 190, in _async_refresh
self.data = await self._async_update_data()
File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 150, in _async_update_data
return await self.update_method()
File "/config/custom_components/babybuddy/__init__.py", line 134, in async_update
if children_list[ATTR_COUNT] == 0:
KeyError: 'count'
2022-04-24 10:40:24 DEBUG (MainThread) [custom_components.babybuddy] Finished fetching babybuddy data in 0.004 seconds (success: False)
2022-04-24 10:41:24 DEBUG (MainThread) [custom_components.babybuddy.client] GET URL: http://192.168.1.34/api/children/
2022-04-24 10:41:24 DEBUG (MainThread) [custom_components.babybuddy.client] GET response: <!doctype html>
<html lang='en'>
<head>
<meta charset='utf-8'>
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>● 192.168.1.34</title>
<link rel='stylesheet' href='/pihole/blockingpage.css'>
<link rel='shortcut icon' href='/admin/img/favicons/favicon.ico' type='image/x-icon'>
</head>
<body id='splashpage'>
<div id="pihole_card">
<img src='/admin/img/logo.svg' alt='Pi-hole logo' id="pihole_logo_splash" />
<p>Pi-<strong>hole</strong>: Your black hole for Internet advertisements</p>
<a href='/admin'>Did you mean to go to the admin panel?</a>
</div>
</body>
</html>

My understanding is DRF extends Django HttpRequest(). Django first checks "HTTP_X_FORWARDED_HOST (if USE_X_FORWARDED_HOST is enabled) and HTTP_HOST headers, in that order. If they don’t provide a value, the method uses a combination of SERVER_NAME and SERVER_PORT."

I am happy to continue helping you fix your problem, but cannot help much more if you are cannot test your reverse proxy settings.

I will have a dig around and see what I can do. I'm not too sure what I need to modify through NGINX proxy manager, but I'll do some googling and see how I go. I do appreciate your efforts. I'm not as much as a wiz as I once was unfortunately

I stopped my nginx proxy and set up BB HA integration with the internal IP and port of BB installation and set up reports it was successful but no sensors are available and the error message stays the same:

Error fetching babybuddy data: Cannot connect to host 192.168.200.2:80 ssl:default [Connect call failed ('192.168.200.2', 80)]

So i think we can agree that nginx configuration does not affect this error.

Maybe @kazzaw can confirm this at some time.

The HA integration is configured to call port 8000. It's actually calling port 80. That's a bug in this package.

The fact that messing with Django/BB config "fixes" it is likely only because it opens port 80.

As others have said, reverse proxy has nothing to do with it since this is a call between two Docker containers on the same machine.

Your own debug logs show the host:port correctly until it hits /api/ endpoints, which is on the BB/Django side of things:

Those logs are entirely from the HA integration. The HA integration is calling port 80 instead of 8000. Unless you're saying that those logs are somehow introspected from BB itself.

I agree but i have to add as well that the bug is probably on BB/Django side:

Looks like the port is missing in the API endpoint list response JSON as i pointed out here: babybuddy/babybuddy#446

Thanks for a more thorough explanation. It was not obvious that the HA integration actually reads the endpoints, including port, from BB. So that could be a BB bug.

I'm guessing your docker-compose.yaml looks similar to this?

services:
 app:
  environment:
   - CSRF_TRUSTED_ORIGINS=http://localhost:8000
   - DJANGO_SETTINGS_MODULE=babybuddy.settings.base
  image: ghcr.io/linuxserver/babybuddy
  ports:
   - '8000:8000'

If so, I'm able to reproduce the issue:

http://localhost:8000/api/ returns: {"children":"http://localhost/api/children/","changes":"http://localhost/api/changes/","feedings":"http://localhost/api/feedings/","notes":"http://localhost/api/notes/","sleep":"http://localhost/api/sleep/","temperature":"http://localhost/api/temperature/","timers":"http://localhost/api/timers/","tummy-times":"http://localhost/api/tummy-times/","weight":"http://localhost/api/weight/","height":"http://localhost/api/height/","head-circumference":"http://localhost/api/head-circumference/","bmi":"http://localhost/api/bmi/"}.

I think the problem may be here:

https://github.com/linuxserver/docker-babybuddy/blob/21b1afc9405d70aba0630054fdd07e0a6ff22a0e/root/defaults/default#L12

When I change the LSIO nginx.conf from proxy_set_header Host $host; to proxy_set_header Host $http_host;, all works as expected:

{"children":"http://localhost:8000/api/children/","changes":"http://localhost:8000/api/changes/","feedings":"http://localhost:8000/api/feedings/","notes":"http://localhost:8000/api/notes/","sleep":"http://localhost:8000/api/sleep/","temperature":"http://localhost:8000/api/temperature/","timers":"http://localhost:8000/api/timers/","tummy-times":"http://localhost:8000/api/tummy-times/","weight":"http://localhost:8000/api/weight/","height":"http://localhost:8000/api/height/","head-circumference":"http://localhost:8000/api/head-circumference/","bmi":"http://localhost:8000/api/bmi/"}

I am going to open a PR with LSIO and see what they think.

Thanks all.

@jcgoette great catch! I haven't even thought about the Lsio docker image having a nginx proxy as well...

Let's hope on a quick merge! Thanks for your help!

@jcgoette i tried out the potential fix from linuxserver/docker-babybuddy#19 but sadly it does not fix the problem on my side.

I also had the same error when trying to call a service through the internal docker network, which previously worked:

Cannot connect to host babybuddy:80 ssl:default [Connect call failed ('172.20.0.2', 80)]

After modifying my docker compose to the following, service calls began working as expected.

  ports:
   - '8000:8000'
   - '80:80'

I still have this issue with the most recent update from lsio. Anyone else?

Yeah this is still broken in Baby Buddy v1.10.2-ls33

ls33 is from 4/17. This fix looks like it was put on https://github.com/linuxserver/docker-babybuddy/releases/tag/v1.10.2-ls36.

Sorry, still a problem with v1.10.2-ls37 as well (have I mentioned how much I hate Docker versioning and "tags"? 😄)

I tried explicitly exposing port 8000 on the babybuddy container to no effect. I cannot expose port 80 (already in use), nor would I want to.

I am running 1.10.2-ls36 just FYI

I mistakenly thought the PR would fix this automatically. You will still need to take some action. See links below:

Manually changing the mounted file /config/nginx/site-confs/default and restarting the container fixes the problem! thanks everyone!

Can you confirm what you changed? Appreciated

I mounted /config as a volume of the container and the change from this commit: https://github.com/linuxserver/docker-babybuddy/pull/19/files in the file /config/nginx/site-confs/default.