Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

No more entities available after HA Core Update 2024.1.0 #23

Open
silub80 opened this issue Jan 4, 2024 · 34 comments
Open

No more entities available after HA Core Update 2024.1.0 #23

silub80 opened this issue Jan 4, 2024 · 34 comments

Comments

@silub80
Copy link

silub80 commented Jan 4, 2024

Hi,
after Update to HA Core 2024.1.0 no more mobile alerts enties are available.
I´m running HA OS 11.2 in a Virual Machine on a Synology DS920+

I´m using TFA30.3060.01 & MA10120.

Maybe anyone could help to solve the issue?

Many Thanks
@kalleylimaki
Copy link

I have the same problem.
My sensor log alert.

Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 360, in _async_setup_platform
await asyncio.shield(task)
File "/config/custom_components/mobile_alerts/binary_sensor.py", line 234, in async_setup_entry
async_add_entities(create_gateway_binary_sensor_entities(coordinator.gateway))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/mobile_alerts/binary_sensor.py", line 190, in create_gateway_binary_sensor_entities
return [
^
File "/config/custom_components/mobile_alerts/binary_sensor.py", line 191, in
MobileAlertesGatewayBinarySensor(
File "/config/custom_components/mobile_alerts/binary_sensor.py", line 79, in init
description.translation_key = description.key
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "", line 4, in setattr
dataclasses.FrozenInstanceError: cannot assign to field 'translation_key'

@ilwalti
Copy link

ilwalti commented Jan 4, 2024 •
edited
Loading

Ditto.
I think that this project was abandoned... too bad.

@AfRotaker
Copy link

Is there some way to contact the author?

@ilwalti
Copy link

ilwalti commented Jan 5, 2024

Don't know... he (@PlusPlus-ua) is silent since 6 months ago.

@dcear
Copy link

dcear commented Jan 5, 2024 via email

@RaRo1980
Copy link

RaRo1980 commented Jan 5, 2024

at the moment i changed to this integration and works well
https://github.com/CestLaGalere/mobilealerts

@silub80
Copy link
Author

silub80 commented Jan 5, 2024

CestLaGalere works but cloud based only. It's better than nothing.

The Advantage from ha_mobilealerts is 100% local with much more faster update intervals. Hopefully it will work again soon

@newslettersns2000
Copy link

I have the same problem.

@gianb80
Copy link

gianb80 commented Jan 8, 2024

Me too :-(

@rodtrip2
Copy link

rodtrip2 commented Jan 8, 2024

The problem seems to be with a missing python library :

2024-01-08 12:34:30.497 ERROR (MainThread) [homeassistant.config_entries] Error importing platform config_flow from integration mobile_alerts to set up mobile_alerts configuration entry: cannot import name 'CONF_GATEWAY' from 'custom_components.mobile_alerts.const' (/config/custom_components/mobile_alerts/const.py)

A lot of custom integrations seem to have similar problems. Hope that home assistant publishes a global fix, or that somebody knows enough about python to fix this addon.

@larobo
Copy link

larobo commented Jan 8, 2024 •
edited
Loading

The problem seems to be that "suddenly" Home assistant core made the EntityDescription object immutable. A good description and and example fix here: ben8p/home-assistant-bunq-balance-sensors#15.

After correcting the installed Python files (binary_sensor.py and sensor.py) Mobile-Alerts seems to work again with HA 2024.1.2.

@rodtrip2
Copy link

rodtrip2 commented Jan 8, 2024

The problem seems to be that "suddenly" Home assistant core made the EntityDescription object immutable. A good description and and example fix here: ben8p/home-assistant-bunq-balance-sensors#15.

After correcting the installed Python files (binary_sensor.py and sensor.py) Mobile-Alerts seems to work again with HA 2024.1.2.

Thanks for finding the problem! Would it be possible to tell us what you changed exactly, or to fork the custom integration?

@larobo
Copy link

larobo commented Jan 9, 2024 •
edited
Loading

I would expect HA to roll-back the pre-mature immutable "feature". I've attached the fixes I've made (done without much insight in HA development). They work for me but use at your own risk,

The fixes are simple, like replace

description.translation_key = description.key

with this

description = dataclasses.replace(
    description,
    translation_key = description.key
)

2024.1-fixes.zip

@gianb80
Copy link

gianb80 commented Jan 9, 2024

Many thanks, but even if HA releases the roll-back, then this FIX will still be fine, since in the future HA will bring this implementation back into effect, correct?

@Iminet72
Copy link
Contributor

Iminet72 commented Jan 9, 2024

Thanks for the fix
I put it together and asked for combing, if it doesn't work, I'll offer the fork I have for use

@Iminet72 Iminet72 mentioned this issue Jan 9, 2024
Open
@Iminet72
Copy link
Contributor

Iminet72 commented Jan 9, 2024

I've been using my own fork for a long time now.
I try to keep it fresh. although I'm just now making friends with programming.
If anyone wants to use it, it works for me

@AfRotaker
Copy link

I would expect HA to roll-back the pre-mature immutable "feature". I've attached the fixes I've made (done without much insight in HA development). They work for me but use at your own risk,

The fixes are simple, like replace

description.translation_key = description.key

with this

description = dataclasses.replace(
    description,
    translation_key = description.key
)

2024.1-fixes.zip

Thank you so much!

@yah996
Copy link

yah996 commented Jan 10, 2024

Thanks for your update...

Found another problem. 2024.x HA can not publish (MQTT) the state attribute "last_update" anymore. So bad.

MQTT Publish code
payload: {{ state_attr('sensor.temperature_sensor_in_cable_0XXXXXXXXXXX_cable_temperature','last_update') }}

{{ ( state_attr('sensor.temperature_sensor_in_cable_0XXXXXXXXXX_cable_temperature','last_update')) }} says None!

Thanks for your help.

@yah996
Copy link

yah996 commented Jan 10, 2024

Fixed it... I changed last_update to last_updated

@silub80
Copy link
Author

silub80 commented Jan 10, 2024 •
edited
Loading

Fixed it... I changed last_update to last_updated

where did you fixed that - in binary_sensor.py and sensor.py only?

@yah996
Copy link

yah996 commented Jan 10, 2024

I changed my automation, I left the py script files as there were. It works for me.

@silub80
Copy link
Author

silub80 commented Jan 11, 2024 •
edited
Loading

I think we can mark this issue as solved trough larobo

#23 (comment)

@silub80 silub80 closed this as completed Jan 11, 2024
@silub80 silub80 reopened this Jan 11, 2024
erkki193236 added a commit to erkki193236/ha_mobilealerts that referenced this issue Jan 12, 2024
@erkki193236
fixed based on PlusPlus-ua#23 (comment)
4240ad8
@kucerazdenek
Copy link

@larobo and others, I would like to ask you, if you would be so kind and someone of you would be able to amend current repo and add
state_class: measurement to all sensors to keep long term statistic in HA? All values are purged after 10 days currently, when I checked other temperature sensors provided by other integrations, those keep long term statistics and only difference in sensor state is state_class.

This one (MFA) is purged
image

This one (Shelly) keeps long-term statistics:, has state_class set
image

@kucerazdenek
Copy link

I tried to do it by myself, just added single row of code
state_class=SensorStateClass.MEASUREMENT,
into following block in sensor.py:

descriptions: dict[MeasurementType, SensorEntityDescription] = {
    MeasurementType.TEMPERATURE: SensorEntityDescription(
        key=None,
        device_class=SensorDeviceClass.TEMPERATURE,
        state_class=SensorStateClass.MEASUREMENT,
        native_unit_of_measurement=UnitOfTemperature.CELSIUS,

but, does anyone know if only new readings pulled after this change will be kept for period longer than 10 days, or this change should be retrospective?
I am asking, because I did this change yesterday afternoon and data older than 10 days are still purged this morning.

Current status of temperature sensor in HA (state_class is present now)
image

@hiatsu0
Copy link

hiatsu0 commented Mar 19, 2024 •
edited
Loading

If it shows attributes like that, then long term stats should work indeed. But only for states that had that attribute I think. If you are impatient to wait 10 days, set your purge delay to 1 day and see if the stats remain :)

Great work btw, will add this line myself too!

@kucerazdenek
Copy link

Make sense, thanks for explanation! :)
I will probably do the same for humidity sensors.

mrworm added a commit to mrworm/ha_mobilealerts that referenced this issue Apr 7, 2024
@mrworm
Update binary_sensor.py
9be8ef0 
PlusPlus-ua#23
mrworm added a commit to mrworm/ha_mobilealerts that referenced this issue Apr 7, 2024
@mrworm
Update sensor.py
0d411e0 
PlusPlus-ua#23
mrworm added a commit to mrworm/ha_mobilealerts that referenced this issue Apr 7, 2024
@mrworm
Update base.py
cb38249 
PlusPlus-ua#23
@marek-veber
Copy link

marek-veber commented Apr 19, 2024 •
edited
Loading

I have been solving the same issue #25 :D

I had two issues:

  1. the need of dataclasses.replace
  2. after the battery stoped working - > then the value unavailable cannot be converted by int(...) of float(....)

I expect that the 1st issue will be also solved by this PullRequest. I'll check it on my instance.
2nd issue should be addressed by a separate new GitHub issue and PullRequest ;)

@berndh11
Copy link

thanks again to Iminet72! He solved perfectly the problem in the pull request.

@uschindler
Copy link

uschindler commented Oct 19, 2024 •
edited
Loading

Hi,
I tried to install the fork of @Iminet72. It install successfully and no python errors are happening. It detects the MobileAlerts Gateway successfully and adds the config for it. But when it then starts the integration it hangs repeating the same over and over (the first part of the log is printed with debugging enabled for the integration, so it successfully gets all information from the gateway and in CAN READ the configuration). But at end it can't enable the integration.

2024-10-19 15:55:36.154 DEBUG (MainThread) [custom_components.mobile_alerts.config_flow] async_step_single_gateway gateway MOBILEALERTS-Gateway V1.50, SerialNo: xxxx (id: xxxx)
Use DHCP: Yes
DHCP IP: 192.168.1.7
Fixed IP: 192.168.1.222
Fixed Netmask: 255.255.255.0
Fixed Gateway: 192.168.1.254
Fixed DNS: 192.168.1.253
Cloud Server: www.data199.com
Use Proxy: No
Proxy Server: 192.168.1.1
Proxy Port: 8080
Send data to cloud: Yes
Last Contact: Sat Oct 19 15:55:34 2024
2024-10-19 15:55:38.499 DEBUG (MainThread) [custom_components.mobile_alerts.config_flow] async_step_single_gateway gateway MOBILEALERTS-Gateway V1.50, SerialNo: xxxx(id: xxxxxx)
Use DHCP: Yes
DHCP IP: 192.168.1.7
Fixed IP: 192.168.1.222
Fixed Netmask: 255.255.255.0
Fixed Gateway: 192.168.1.254
Fixed DNS: 192.168.1.253
Cloud Server: www.data199.com
Use Proxy: No
Proxy Server: 192.168.1.1
Proxy Port: 8080
Send data to cloud: Yes
Last Contact: Sat Oct 19 15:55:34 2024
2024-10-19 15:55:38.500 DEBUG (MainThread) [custom_components.mobile_alerts] async_setup_entry {'created_at': '2024-10-19T13:55:38.499783+00:00', 'data': {'send_data_to_cloud': True}, 'disabled_by': None, 'domain': 'mobile_alerts', 'entry_id': '01JAJGZWC3CH0DMQ1ZKY7SW2T2', 'minor_version': 1, 'modified_at': '2024-10-19T13:55:38.499791+00:00', 'options': {}, 'pref_disable_new_entities': False, 'pref_disable_polling': False, 'source': 'user', 'title': 'xxxx', 'unique_id': 'xxxx', 'version': 1}
2024-10-19 15:56:13.863 DEBUG (MainThread) [custom_components.mobile_alerts] async_setup_entry {'created_at': '2024-10-19T13:55:38.499783+00:00', 'data': {'send_data_to_cloud': True}, 'disabled_by': None, 'domain': 'mobile_alerts', 'entry_id': '01JAJGZWC3CH0DMQ1ZKY7SW2T2', 'minor_version': 1, 'modified_at': '2024-10-19T13:55:38.499791+00:00', 'options': {}, 'pref_disable_new_entities': False, 'pref_disable_polling': False, 'source': 'user', 'title': 'xxxx', 'unique_id': 'xxxx', 'version': 1}
2024-10-19 15:56:54.379 DEBUG (MainThread) [custom_components.mobile_alerts] async_setup_entry {'created_at': '2024-10-19T13:55:38.499783+00:00', 'data': {'send_data_to_cloud': True}, 'disabled_by': None, 'domain': 'mobile_alerts', 'entry_id': '01JAJGZWC3CH0DMQ1ZKY7SW2T2', 'minor_version': 1, 'modified_at': '2024-10-19T13:55:38.499791+00:00', 'options': {}, 'pref_disable_new_entities': False, 'pref_disable_polling': False, 'source': 'user', 'title': 'xxxx', 'unique_id': 'xxxx', 'version': 1}
2024-10-19 15:57:44.668 DEBUG (MainThread) [custom_components.mobile_alerts] async_setup_entry {'created_at': '2024-10-19T13:55:38.499783+00:00', 'data': {'send_data_to_cloud': True}, 'disabled_by': None, 'domain': 'mobile_alerts', 'entry_id': '01JAJGZWC3CH0DMQ1ZKY7SW2T2', 'minor_version': 1, 'modified_at': '2024-10-19T13:55:38.499791+00:00', 'options': {}, 'pref_disable_new_entities': False, 'pref_disable_polling': False, 'source': 'user', 'title': 'xxxx', 'unique_id': 'xxxx', 'version': 1}
2024-10-19 15:58:55.096 DEBUG (MainThread) [custom_components.mobile_alerts] async_setup_entry {'created_at': '2024-10-19T13:55:38.499783+00:00', 'data': {'send_data_to_cloud': True}, 'disabled_by': None, 'domain': 'mobile_alerts', 'entry_id': '01JAJGZWC3CH0DMQ1ZKY7SW2T2', 'minor_version': 1, 'modified_at': '2024-10-19T13:55:38.499791+00:00', 'options': {}, 'pref_disable_new_entities': False, 'pref_disable_polling': False, 'source': 'user', 'title': 'xxxx', 'unique_id': 'xxxx', 'version': 1}
2024-10-19 16:00:45.376 DEBUG (MainThread) [custom_components.mobile_alerts] async_setup_entry {'created_at': '2024-10-19T13:55:38.499783+00:00', 'data': {'send_data_to_cloud': True}, 'disabled_by': None, 'domain': 'mobile_alerts', 'entry_id': '01JAJGZWC3CH0DMQ1ZKY7SW2T2', 'minor_version': 1, 'modified_at': '2024-10-19T13:55:38.499791+00:00', 'options': {}, 'pref_disable_new_entities': False, 'pref_disable_polling': False, 'source': 'user', 'title': 'xxxx', 'unique_id': 'xxxx', 'version': 1}
2024-10-19 16:02:35.572 DEBUG (MainThread) [custom_components.mobile_alerts] async_setup_entry {'created_at': '2024-10-19T13:55:38.499783+00:00', 'data': {'send_data_to_cloud': True}, 'disabled_by': None, 'domain': 'mobile_alerts', 'entry_id': '01JAJGZWC3CH0DMQ1ZKY7SW2T2', 'minor_version': 1, 'modified_at': '2024-10-19T13:55:38.499791+00:00', 'options': {}, 'pref_disable_new_entities': False, 'pref_disable_polling': False, 'source': 'user', 'title': 'xxxx', 'unique_id': 'xxxx', 'version': 1}

This repeats forever.

Unfortunately the Exception as printed in the UI (interestingly you can't find it in the log file its only printed on the integration configuration page) is not very helpful, it only says that it can't initialize the gateway. It is thrown here: https://github.com/Iminet72/ha_mobilealerts/blob/1d5a70b7f7da7e831ab3139ee82cd9adf430f1ef/custom_components/mobile_alerts/__init__.py#L30-L33

It returns false here in the low level gateway/proxy implementation causing the above exception: https://github.com/PlusPlus-ua/python-mobilealerts/blob/80b4591a3998dcbe62266e6f1294104b4ddeffd5/mobilealerts/gateway.py#L91-L100

I don't understand why the discovery of the gateway worked, but when it wants to enable the integration for the given gateway it fails while parsing the configuration.

Any idea what goes wrong? The above log messages tell me that it find the gateway and can read its configiuration, but why does it fail later when it sets it up for production? I am using Hass 2024.8.3.

@newslettersns2000
Copy link

I have no Problems

@uschindler
Copy link

uschindler commented Oct 19, 2024 •
edited
Loading

Hi, I tried to install the fork of @Iminet72. It install successfully and no python errors are happening. It detects the MobileAlerts Gateway successfully and adds the config for it. But when it then starts the integration it hangs repeating the same over and over (the first part of the log is printed with debugging enabled for the integration, so it successfully gets all information from the gateway and in CAN READ the configuration). But at end it can't enable the integration.

2024-10-19 15:55:36.154 DEBUG (MainThread) [custom_components.mobile_alerts.config_flow] async_step_single_gateway gateway MOBILEALERTS-Gateway V1.50, SerialNo: xxxx (id: xxxx)
Use DHCP: Yes
DHCP IP: 192.168.1.7
Fixed IP: 192.168.1.222
Fixed Netmask: 255.255.255.0
Fixed Gateway: 192.168.1.254
Fixed DNS: 192.168.1.253
Cloud Server: www.data199.com
Use Proxy: No
Proxy Server: 192.168.1.1
Proxy Port: 8080
Send data to cloud: Yes
Last Contact: Sat Oct 19 15:55:34 2024
2024-10-19 15:55:38.499 DEBUG (MainThread) [custom_components.mobile_alerts.config_flow] async_step_single_gateway gateway MOBILEALERTS-Gateway V1.50, SerialNo: xxxx(id: xxxxxx)
Use DHCP: Yes
DHCP IP: 192.168.1.7
Fixed IP: 192.168.1.222
Fixed Netmask: 255.255.255.0
Fixed Gateway: 192.168.1.254
Fixed DNS: 192.168.1.253
Cloud Server: www.data199.com
Use Proxy: No
Proxy Server: 192.168.1.1
Proxy Port: 8080
Send data to cloud: Yes
Last Contact: Sat Oct 19 15:55:34 2024
2024-10-19 15:55:38.500 DEBUG (MainThread) [custom_components.mobile_alerts] async_setup_entry {'created_at': '2024-10-19T13:55:38.499783+00:00', 'data': {'send_data_to_cloud': True}, 'disabled_by': None, 'domain': 'mobile_alerts', 'entry_id': '01JAJGZWC3CH0DMQ1ZKY7SW2T2', 'minor_version': 1, 'modified_at': '2024-10-19T13:55:38.499791+00:00', 'options': {}, 'pref_disable_new_entities': False, 'pref_disable_polling': False, 'source': 'user', 'title': 'xxxx', 'unique_id': 'xxxx', 'version': 1}
2024-10-19 15:56:13.863 DEBUG (MainThread) [custom_components.mobile_alerts] async_setup_entry {'created_at': '2024-10-19T13:55:38.499783+00:00', 'data': {'send_data_to_cloud': True}, 'disabled_by': None, 'domain': 'mobile_alerts', 'entry_id': '01JAJGZWC3CH0DMQ1ZKY7SW2T2', 'minor_version': 1, 'modified_at': '2024-10-19T13:55:38.499791+00:00', 'options': {}, 'pref_disable_new_entities': False, 'pref_disable_polling': False, 'source': 'user', 'title': 'xxxx', 'unique_id': 'xxxx', 'version': 1}
2024-10-19 15:56:54.379 DEBUG (MainThread) [custom_components.mobile_alerts] async_setup_entry {'created_at': '2024-10-19T13:55:38.499783+00:00', 'data': {'send_data_to_cloud': True}, 'disabled_by': None, 'domain': 'mobile_alerts', 'entry_id': '01JAJGZWC3CH0DMQ1ZKY7SW2T2', 'minor_version': 1, 'modified_at': '2024-10-19T13:55:38.499791+00:00', 'options': {}, 'pref_disable_new_entities': False, 'pref_disable_polling': False, 'source': 'user', 'title': 'xxxx', 'unique_id': 'xxxx', 'version': 1}
2024-10-19 15:57:44.668 DEBUG (MainThread) [custom_components.mobile_alerts] async_setup_entry {'created_at': '2024-10-19T13:55:38.499783+00:00', 'data': {'send_data_to_cloud': True}, 'disabled_by': None, 'domain': 'mobile_alerts', 'entry_id': '01JAJGZWC3CH0DMQ1ZKY7SW2T2', 'minor_version': 1, 'modified_at': '2024-10-19T13:55:38.499791+00:00', 'options': {}, 'pref_disable_new_entities': False, 'pref_disable_polling': False, 'source': 'user', 'title': 'xxxx', 'unique_id': 'xxxx', 'version': 1}
2024-10-19 15:58:55.096 DEBUG (MainThread) [custom_components.mobile_alerts] async_setup_entry {'created_at': '2024-10-19T13:55:38.499783+00:00', 'data': {'send_data_to_cloud': True}, 'disabled_by': None, 'domain': 'mobile_alerts', 'entry_id': '01JAJGZWC3CH0DMQ1ZKY7SW2T2', 'minor_version': 1, 'modified_at': '2024-10-19T13:55:38.499791+00:00', 'options': {}, 'pref_disable_new_entities': False, 'pref_disable_polling': False, 'source': 'user', 'title': 'xxxx', 'unique_id': 'xxxx', 'version': 1}
2024-10-19 16:00:45.376 DEBUG (MainThread) [custom_components.mobile_alerts] async_setup_entry {'created_at': '2024-10-19T13:55:38.499783+00:00', 'data': {'send_data_to_cloud': True}, 'disabled_by': None, 'domain': 'mobile_alerts', 'entry_id': '01JAJGZWC3CH0DMQ1ZKY7SW2T2', 'minor_version': 1, 'modified_at': '2024-10-19T13:55:38.499791+00:00', 'options': {}, 'pref_disable_new_entities': False, 'pref_disable_polling': False, 'source': 'user', 'title': 'xxxx', 'unique_id': 'xxxx', 'version': 1}
2024-10-19 16:02:35.572 DEBUG (MainThread) [custom_components.mobile_alerts] async_setup_entry {'created_at': '2024-10-19T13:55:38.499783+00:00', 'data': {'send_data_to_cloud': True}, 'disabled_by': None, 'domain': 'mobile_alerts', 'entry_id': '01JAJGZWC3CH0DMQ1ZKY7SW2T2', 'minor_version': 1, 'modified_at': '2024-10-19T13:55:38.499791+00:00', 'options': {}, 'pref_disable_new_entities': False, 'pref_disable_polling': False, 'source': 'user', 'title': 'xxxx', 'unique_id': 'xxxx', 'version': 1}

This repeats forever.

Unfortunately the Exception as printed in the UI (interestingly you can't find it in the log file its only printed on the integration configuration page) is not very helpful, it only says that it can't initialize the gateway. It is thrown here: https://github.com/Iminet72/ha_mobilealerts/blob/1d5a70b7f7da7e831ab3139ee82cd9adf430f1ef/custom_components/mobile_alerts/__init__.py#L30-L33

It returns false here in the low level gateway/proxy implementation causing the above exception: https://github.com/PlusPlus-ua/python-mobilealerts/blob/80b4591a3998dcbe62266e6f1294104b4ddeffd5/mobilealerts/gateway.py#L91-L100

I don't understand why the discovery of the gateway worked, but when it wants to enable the integration for the given gateway it fails while parsing the configuration.

Any idea what goes wrong? The above log messages tell me that it find the gateway and can read its configiuration, but why does it fail later when it sets it up for production? I am using Hass 2024.8.3.

I found out where this issue comes from. It has nothing to do with the changes proposed here. The issue is simple:
My Hass server has multiple network interfaces and IP addresses. When the config workflow does the lookuop it passes HASS IP as configured in the network interfaces as "base" address for the discovery. This IP address is retrieved from hass, see here:

ha_mobilealerts/custom_components/mobile_alerts/config_flow.py

Lines 115 to 120 in 8143b11

gateways = []
ip_address = await async_get_source_ip(self.hass)
try:
gateways = await Gateway.discover(ip_address)
except socket.error as err:
_LOGGER.error("Gateways discovery error %r", err)

Unfortunately when the implementation starts it can't find the gateway and more (to set the proxy port and IP address) of proxy, because the broadcast is sent with None as source address. In case of multiple network interfaces, the system does not know what interface to use to send the broadcast for reconfiguring the gateway.

Basically, my quick hack was simple, just modify the main.py file and hardcode my internal IP address as 2nd parameter to new Gateway(). The correct fix is to move the proxy_ip a few lines below up:

    proxy_ip = await async_get_source_ip(hass, gateway_ip)

and use it for discovery.

I will open a separate issue. As this repository seems dead, is anybody willing to host a patched/forked version? @Iminet72 are you willing to take over the repo, i would open a PR in your fork then? Otherwise I can also fork the repo and make my own impl with all fixes applied (including the one with broadcast source address).

@uschindler uschindler mentioned this issue Oct 19, 2024
Open
@uschindler
Copy link

I opened #26 about the broadcast source IP address issue.

@berndh11
Copy link

berndh11 commented Oct 20, 2024 via email

@uschindler
Copy link

Hi Bernd,

Hallo Uwe, ich gehe davon aus dass du Deutsch sprichst nach deinem Namen zu urteilen. Am besten ich schicke dir mal die beiden Dateien per E-Mail und dann kannst du die einfach in Home Assistant hochladen. Dann müsste alles gehen. Wenn es dann immer noch nicht geht, ist mit deiner Konfiguration etwas nicht in Ordnung bzw irgendein Update macht Schwierigkeiten. Ich habe allerdings alle Updates installiert und bei mir läuft alles tadellos. Viele Grüße. Bernd

Das Problem mit der Discovery hat mit dem Problem hier nichts zu tun, ich habe neuen Issue aufgemacht. Bitte vollständig lesen. Siehe #26. Es handelt sich um einen weiteren Fehler der in Konfigurationen mit mehreren Netzwerkenschnittstellen passiert. Es wurde nur vergessen die spezifische/passende Source IP Adresse bei Aktivierung des Gateways zu benutzen, was dann dazu führt dass das Gateway später nicht mehr gefunden wird.

Uwe

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests