search

Tidone / homeassistant_eta_integration

Integration of ETA (Heating) sensors and switches to home assistant
MIT License
21 stars 1 forks source link

Switching from nigl to tidone #9

Open hubtub2 opened 7 months ago

hubtub2 commented 7 months ago

Hi,

I am just trying to switch from nigls integration to your integration to have access to the switches.

When I start the configuration dialog, it takes quite some time, then the sensors/switches/... dialog pops up, but does not contain any entries:

grafik

I tried with IP and with URL. Things worked before with my own and with nigls integration, installation was some time ago though.

This is my user/api at http://eta-pelletheizung.fritz.box:8080/user/api

<eta version="1.0">
<api version="1.2"/>
</eta>

An this the start of my user/menu

<eta version="1.0">
<menu>
<fub uri="/40/10021" name="Kessel">
<object uri="/40/10021/0/0/10990" name="Eingänge">
<object uri="/40/10021/0/11031/0" name="Wassermangel">
<object uri="/40/10021/0/11031/2012" name="Einschalt Verz."/>
<object uri="/40/10021/0/11031/2013" name="Ausschalt Verz."/>
<object uri="/40/10021/0/11031/2016" name="Eingang"/>
<object uri="/40/10021/0/11031/2017" name="Eingang"/>
</object>
<object uri="/40/10021/0/11032/0" name="Not-Aus Schalter">
<object uri="/40/10021/0/11032/2012" name="Einschalt Verz."/>
<object uri="/40/10021/0/11032/2013" name="Ausschalt Verz."/>
<object uri="/40/10021/0/11032/2016" name="Eingang"/>
<object uri="/40/10021/0/11032/2017" name="Eingang"/>
</object>
hubtub2 commented 7 months ago

Interestingly, the "latest error entity" works and shows that I should empty the ashes box:

grafik

hubtub2 commented 7 months ago

Another thing I noticed, is that es entities from the nigl integration are still there, even after a reboot, and I don't know how to get rid of them. But this should not cause this problem, right?

Update: those are just the entities that are still used in the UI/cars and will probably disappear as soon as I update the UI with the new entities.

grafik

Tidone commented 7 months ago

Hi,

Both, IP and hostname, should work as long as you leave out the http:// prefix.

Which version of Homeassistant are you using? I just set up a testing environment with HA 2023.10 and this integration v1.1.1, and I could not reproduce the problem.

The old entities are no problem, because my integration uses a different entity ID prefix. So you could in theory run both integrations at the same time, but I never tested this. And as you noticed, they should all still be in use by some dashboard/automation, and will disappear when they aren't referenced anymore. And the reason why the error sensors are working is because they are using a hard-coded endpoint (/user/errors), and any bug which affects the detection of the other sensors, doesn't affect these ones.

Could you post the output of http://<host>:port/user/varinfo/40/10021/0/11108/0 and http://<host>:port/user/var/40/10021/0/11108/0. This should be the Restsauerstoff sensor.

Also, please check if there are any errors logged in Settings -> System -> Logs. Could you also please post the diagnostics info? You can download them on the device page, in the Device Info panel on the top left, under the three dot menu.

hubtub2 commented 7 months ago

Hello,

Thank you for the quick reply. I am using HA core 2024.1.2 Integration is 1.1.1

Here is the diagnostic info from the device: config_entry-hacs-7a4dd4da386249f238d1274bff777e66.json.txt

No entries in the System Logs that seem to be related.

The two outputs for the "Restsauerstoff" are:

<eta version="1.0">
<varInfo uri="/user/varinfo/40/10021/0/11108/0">
<variable uri="40/10021/0/11108/0" name="Restsauerstoff" fullName="Eingänge > Restsauerstoff" unit="%" decPlaces="1" scaleFactor="100" advTextOffset="0" isWritable="0">
<type>DEFAULT</type>
</variable>
</varInfo>
</eta>
<eta version="1.0">
<value uri="/user/var/40/10021/0/11108/0" strValue="9,2" unit="%" decPlaces="1" scaleFactor="100" advTextOffset="0">924</value>
</eta>
Tidone commented 7 months ago

The output of the two endpoints looks alright. The config dialog should show at least that sensor.

Could you check that you downloaded the correct diagnostics info? The file you provided was generated by HACS, not by eta webservices (this integration).

I guess HA changed some of it's internal handling of integrations, which causes the config dialog to not show any sensors. I will update my testing environment and look into it.

hubtub2 commented 7 months ago

Here is the correct diagnostics info:

config_entry-eta_webservices-a199866bb8cc4dcaebe422b24c1e3238.json.txt

It says version 1.1.0? I am pretty sure, that I installed 1.1.1 with HACS.

Tidone commented 7 months ago

Thanks, unfortunately I couldn't reproduce the bug on the new HA version. You diagnostics info also doesn't show any problem. The eta menu is correctly parsed, but the list of available sensors is empty.

I just pushed a new version, which adds a legace API mode, and some debug logging.

Could you please do the following:

  1. Update the ETA integration
  2. Restart HA if possible (to make sure the debug logs do not show old entries)
  3. Go to the integration page in HA (the one where you can click the Configure button)
  4. Click on Enable debug logging Debug logging
  5. Click on the three dots on the right and select Delete
  6. Click on Add entry and configure the integration
  7. After configuration is done, click on Disable debug logging.
  8. This will trigger a file download. Save the file and upload it here

This debug log should tell me why the sensors are not added in your case.

You could also try enabling the new Force old API mode setting when adding the integration. This will force the old API handling, which should be the same as in nigl's integration.

hubtub2 commented 7 months ago

Much appreciated! I will test as soon as possible (this weeks is super full).

hubtub2 commented 6 months ago

Today, after updating home assistant & hacs, i updated to 1.1.3. The "Enable debug logging" entry does not exist any more?.

I tried to install with the new "verbose log" checked. Same result, no entries in the dialog.

I could attach the "verbose log" - but where do I find it?

Tidone commented 6 months ago

Hi, you can find the logs in Settings -> System -> Logs and then click on Download Full Log at the bottom of the page.

It may be better to restart home assistant before trying to add this integration again with verbose logging enabled, and then download the logs. That way the logs are cleared and do not contain potentially weeks of data.

hubtub2 commented 6 months ago

Here are the full logs. I restarted first. Then removed the integration entry for eta and added a new integration entry. As always, the dialog was not populated with sensors. home-assistant_2024-03-17T20-42-01.467Z.log

hubtub2 commented 6 months ago

Btw. the "force old API" option works for me with 1.1.3

Tidone commented 6 months ago

Do you have access to a Linux machine, or Windows WSL?

According to your logs the ETA unit responds with an invalid status code to every varinfo request, which causes an exception to be thrown for every endpoint. This in turn means that no sensors will be added to the lists of valid sensors.

hubtub2 commented 6 months ago

I will do, when I am home. I am on MacOS no problem, but I could also just do the http request in any web browser, right? Maybe I have an older ETA firmware that does not support "/varinfo/"?

Tidone commented 5 months ago

I need the raw response headers, including the http status code, to make sure I found the problem. That's why I posted the verbose curl commands. You can also do the request in a web browser, but you need to open the network tab in the developer tools before. After sending the request you can select the request in the dev tools, right click on it and copy the response headers.

We already tried the varinfo endpoint, and your ETA unit definitely supports it, but it looks like your ETA unit is responding with an invalid http status code.

hubtub2 commented 5 months ago

Ok understand. I get

$ curl -vv http://192.168.178.47:8080/user/varinfo/40/10021/0/11108/0
*   Trying 192.168.178.47:8080...
* Connected to 192.168.178.47 (192.168.178.47) port 8080 (#0)
> GET /user/varinfo/40/10021/0/11108/0 HTTP/1.1
> Host: 192.168.178.47:8080
> User-Agent: curl/7.87.0
> Accept: */*
> 
* Unsupported response code in HTTP response
* Closing connection 0
curl: (1) Unsupported response code in HTTP response

Curl does not show the header. Using the same URL in chrome works as expected.

Also for /var/ the curl result is as expected:

curl -vv http://192.168.178.47:8080/user/var/40/10021/0/11108/0
*   Trying 192.168.178.47:8080...
* Connected to 192.168.178.47 (192.168.178.47) port 8080 (#0)
> GET /user/var/40/10021/0/11108/0 HTTP/1.1
> Host: 192.168.178.47:8080
> User-Agent: curl/7.87.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Length: 235
< Content-Type: application/xml;charset=UTF-8
< Cache-Control: no-cache
< Date: Mon, 18 Mar 2024 21:50:05 GMT
< 
<?xml version="1.0" encoding="utf-8"?>
<eta version="1.0" xmlns="http://www.eta.co.at/rest/v1">
  <value uri="/user/var/40/10021/0/11108/0" strValue="20,1" unit="%" decPlaces="1" scaleFactor="100" advTextOffset="0">2012</value>
</eta>
* Connection #0 to host 192.168.178.47 left intact

Here is the same using Chrome and the network tab:

Using /varinfo/:

HTTP/1.1 0 Unknown
Content-Length: 387
Content-Type: application/xml;charset=UTF-8
Cache-Control: no-cache
Date: Mon, 18 Mar 2024 22:00:36 GMT

Using /var/:

HTTP/1.1 200 OK
Content-Length: 235
Content-Type: application/xml;charset=UTF-8
Cache-Control: no-cache
Date: Mon, 18 Mar 2024 22:01:59 GMT

So ETA sends the response code "0", which usually means "no response" - and then sends a response body anyways? Sounds like a bug to me. Can you work around this in python somehow? Or maybe I should try updating my ETA firmware - but I would have to find out how to do this ...

Tidone commented 5 months ago

Thanks for the info! That's what I thought. Your ETA unit sends a valid response, but with an invalid http response code, and most http parsers refuse to decode this.

I will have to check if I can ignore this error in python, but this may take some time because I'll also have to set up a small dev webserver to be able to reproduce this.

Updating the firmware of the ETA unit should be easy. You just have to download the correct firmware file from meinETA, put it on a FAT32 USB stick, and when you plug it into the heater unit it should offer you to update its firmware. Be careful when downloading the firmware file though, because some newer updates require your unit to be on a specific minimum firmware version. If you are on an older one, you have to update multiple times. But you should not have to update the firmware at all, because never change a running system. If I can't fix this bug you can still force the old API version with this integration.

hubtub2 commented 5 months ago

Yes, never change a running system. If you have an idea for a few lines of code to ignore the response code, I can offer you to quickly test them on my system by just editing the custom_component/ (without creating a release).

Tidone commented 5 months ago

Hi, I implemented a quick fix by monkeypatching a function in aiohttp, which checks the response code: api.zip This version should work in your special case. Just replace the api.py file with the new one if you want to try it.

I don't know if I will publish this fix because monkeypatching a system function is never a good idea.