Hello all. I’ve been having this problem for a while. I believe when the companion app updates, it adds all the sensors again, with a suffix ‘_x’. This messes all my automations that rely on it. I’ve searched the community but could not find any answers. Does anyone have the same issue? How can I fix this?
Thanks.
This should only happen when the integration needs to re-created, and only in 2 scenarios: (1) the device ID changed (which shouldn’t happen unless you deleted the app and reinstalled), and (2) the names changed, which I believe resets 'em.
You can see a log in the app when it recreates the integration, under Preferences > Debugging > Event Log. Click on the row to see the reason why - generally because an HTTP error occurred which indicates the integration was deleted.
Awesome, thank you so much for replying. I wasn’t aware of the ‘event log’ in the app.
I have all these errors caused by “unmappableValue”. Is this what you are referring to? Is there any way of preventing this?
Can you describe your HA setup? How does the app talk to the server? This sounds like the server is returning non-JSON responses at times.
This has happened to me a couple of times over the last few weeks. I don’t install the AppStore version; I download it from github. To install it, I quit the currently running instance and drag the new version into /Applications, replacing the one that’s currently there. Hopefully that’s not deleting the app and reinstalling?
Looking at the log in the application, on both occasions when when the debug log says Integration is missing; registering when doing “Network Request”, the additional information says:
{
"error" : "unmappableValue"
}
any thoughts on how to prevent this from happening in the future?
Over the last week or so, the Linux box running Home Assistant and all the other containers rebooted. So there’s a chance Home Assistant was down and not responding while the application was running. If it wasn’t able to connect to the “LAN”/local port, I wonder if it tried the external URL and got a bad response from my nginx reverse proxy before Home Assistant restarted? This is just a theory; I don’t have any specific evidence this might have happened.
I do not believe that replacing the app will trigger the reinstalled flow, but that’s largely on the Apple side when they decide to reset the “identifier for vendor” (aka HA) value.
What response from your reverse proxy do you get when Home Assistant is down? The following are the cases where the app decides the integration needs to be recreated:
- The response code is status code 410
- The response code is status code 404
- The response code is 2xx and doesn’t look like a webhook response (unmappableValue or unexpectedType)
If your reverse proxy is returning a non-5xx status code when the destination server is down, that’s likely the root cause. Try shutting down that container and seeing what happens.
I was finally able to try to reproduce this problem and see what HTTP error is returned by my reverse proxy when the Home Assistant container isn’t running. It’s returning a 502 Bad Gateway error, which seems reasonable.
When the container isn’t running, and you try to connect to it directly on the LAN it, of course, returns a TCP RST response which is “Connection Refused.”
Here’s the slightly sanitized output from a curl command:
% curl -v https://XXXX:433/
* Trying w.x.y.z:433...
* Connected to XXXX (w.x.y.z) port 433 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* CAfile: /opt/local/share/curl/curl-ca-bundle.crt
* CApath: none
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS header, Finished (20):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.2 (OUT), TLS header, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=XXXX
* start date: Apr 5 05:15:10 2022 GMT
* expire date: Jul 4 05:15:09 2022 GMT
* subjectAltName: host "XXXX" matched cert's "XXXX"
* issuer: C=US; O=Let's Encrypt; CN=R3
* SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* h2h3 [:method: GET]
* h2h3 [:path: /]
* h2h3 [:scheme: https]
* h2h3 [:authority: XXXX:433]
* h2h3 [user-agent: curl/7.82.0]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0x7fe13480a800)
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
> GET / HTTP/2
> Host: XXXX:433
> user-agent: curl/7.82.0
> accept: */*
>
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
* TLSv1.2 (OUT), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
* TLSv1.2 (IN), TLS header, Supplemental data (23):
< HTTP/2 502
< server: nginx
< date: Sun, 24 Apr 2022 02:30:20 GMT
< content-type: text/html
< content-length: 150
<
<html>
<head><title>502 Bad Gateway</title></head>
<body>
<center><h1>502 Bad Gateway</h1></center>
<hr><center>nginx</center>
</body>
</html>
And when trying to connect directly:
% curl 10.200.0.100:8123
curl: (7) Failed to connect to 10.200.0.100 port 8123 after 13 ms: Connection refused
And how would I delete the zombie devices that get created? The DELETE button on the device seems to be disabled?
I’m not able to reproduce a 5xx error code (in my case, a 503 Service Unavailable) causing this integration failure. It correctly realizes it’s transient and ignores it:
2022-04-29 08:10:39.039 [Info] [main] [HAAPI.swift:175] Connect(reason:) > not re-registering, but failed to update registration: unacceptableStatusCode(503)
If you do reproduce it, the full app logs will be the best bet, since you can see the exact error it hit followed by the log line for the integration being reset. Those are in Preferences > Debugging > Reveal logs in finder.
Thanks! I’ll keep this in mind, and grab logs if I see the duplication problem crop up again.
It looks like the logs are accessible through the preferences pane in the debugging tab as you suggested. I’ve not done anything special in regards to any logging configuration (e.g, turning up/down the logging severity, etc.), so I’m hoping that the default logging configuration will be suitable for capturing the relevant event?
The default configuration will capture everything. There’s no option to turn up or down logging in the app.