-
-
Notifications
You must be signed in to change notification settings - Fork 30
[BUG] [Errno -3] Temporary failure in name resolution when using Button entity with own MQTT client #331
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.
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
Comments
I'm suspecting this line is the culprit, since connect_client() is always called without checking whether the client already exists.
Which would mean currently any entity of class subscriber would be affected by this if I understand the code correctly. ha-mqtt-discoverable/ha_mqtt_discoverable/__init__.py Lines 648 to 651 in 8feb496
|
@simonthechipmunk Thanks for your issue report and your initial analysis. I agree and I even see more issues, e.g. the instances of Subscriber rely on the on_connect callback, which is never set and therefor subscribing to the command topic will never happen, when using an external MQTT client. In regards to #194 and this issues all entities have to use the same client and subscribing to a entities' command topic happens successfully. Please give me some time to come up with a fix. |
@kratz00 Thanks for your help. It is much appreciated. |
Signed-off-by: Steffen Pankratz <[email protected]>
#332 - First draft of a possible solution (just a first try, tests are missing etc.). With these changes I can create multiple entities (Discoverable and/or Subscriber based) using an existing MQTT client.
I could not reproduce #192 - all entities create their own MQTT clients and on a first glance everything looks good. Might be a scheduling issue as each MQTT client starts one communication loop thread, which might overwhelm low end hardware. |
I'll start with this one as I'm not sure what's going on myself. The target hardware is a Raspberry pi 3b+ but I experience this behavior on my regular PC too. Here's a basic example again that reproduces the problem. Maybe I'm also just doing something completely wrong since I'm just starting out with threading and MQTT in python: import threading
import time
from paho.mqtt import client as MQTTClient
from ha_mqtt_discoverable import Settings, DeviceInfo
from ha_mqtt_discoverable.sensors import BinarySensor, BinarySensorInfo, Button, ButtonInfo
# Entity instances
sensor: BinarySensor
button: Button
# Define an optional object to be passed back to the callback
user_data = "Button was pressed!"
# To receive button commands from HA, define a callback function:
def my_callback(client: MQTTClient.Client, user_data, message: MQTTClient.MQTTMessage):
print(user_data)
time.sleep(6)
# Sensor test task
def sensortest():
while True:
global sensor
sensor.update_state(True)
time.sleep(1)
sensor.update_state(False)
time.sleep(1)
# Main
if __name__ == "__main__":
# Define the device. At least one of `identifiers` or `connections` must be supplied
device_info = DeviceInfo(name="ButtonSensorTestDevice", identifiers="buttonsensortestdevice1")
# Configure the required parameters for the MQTT broker
mqtt_settings = Settings.MQTT(host="homeassistant.local", client_name="ButtonSensorTestClient", username="mqtt", password="hamqtt")
# Information about the entities
button_info = ButtonInfo(name="Button", unique_id="button12346", device=device_info)
sensor_info = BinarySensorInfo(name="Sensor", unique_id="sensor12347", device_class="motion", device=device_info)
# Create entity settings
sensor_settings = Settings(mqtt=mqtt_settings, entity=sensor_info)
button_settings = Settings(mqtt=mqtt_settings, entity=button_info)
# Instantiate the entities
sensor = BinarySensor(sensor_settings)
button = Button(button_settings, my_callback, user_data)
# Publish the button's discoverability message to let HA automatically notice it
button.write_config()
sensorThread = threading.Thread(target=sensortest)
sensorThread.start()
sensorThread.join() What I see in HA and MQTT explorer is, that the sensor is only sending every 2s, so the state remains either on or off continuously. Interestingly enough if you keep pressing the button eventually a message will come through and as long as the callback is inside the sleep routine, the sensor will start sending its correct values. |
I tested your changes and it worked flawlessly with the external MQTT client and button + sensor. Thank you. The weird behavior with the internal clients described above still persists, but maybe I'm making a rookie mistake on my end? |
@simonthechipmunk Thanks for testing the feature branch, glad it's solving the issue - I will clean up the PR and merge it then. Regarding the other problem, I guess the problems are in regards to all the sleep calls, which basically pause the execution of the thread. You call sleep twice, each with one second - which corresponds to what you see - sensors get updated every 2 seconds only. Can you try reducing the duration e.g. using 0.1 and completely removing the sleep call in the my_callback? |
The sleep call in my_callback was just to show the effect that the callback is having on the sensor thread so it can be removed of course. Between the two sleep calls is another sensor update so the expected behavior is a status change of the sensor every second. However something seems to be blocking it. If I remove the sleep call in my_callback completely and replace the other two with a 0.1s sleep, it's getting somewhere: The sensor is rapidly updating as expected, but there's a disruption every other second with a complete stop of updates for exactly one second. It looks like the connection is briefly dropped and reestablished. I would need to make a Wireshark recording to confirm this, but there is clearly something going on with the callback. Is it maybe blocking the MQTT event loop? This is an entirely different issue though, so this issue regarding the external MQTT client can be closed. |
I did some very hacky stuff to use externally managed MQTT client for devices with multiple buttons: https://github.com/Ginden/home-assistant-remote-commands |
Describe the bug
After I ran into #194 I tried using the own MQTT client approach and handle connecting the MQTT broker myself but this doesn't seem to work with the button entity.
The script stops with a bogus DNS error message:
socket.gaierror: [Errno -3] Temporary failure in name resolution
The network is fine though and Home Assistant is reachable via the hostname (I tried using the IP address directly too). If I use a sensor entity instead of the button the code runs as expected.
It looks like the button entity is trying to connect the already connected client again, but I'm at a loss on why this is happening.
To Reproduce
Here's a minimal example to reproduce:
And the full output:
Expected behavior
The button entity should be advertised to Home Assistant via the existing MQTT client connection
Environment:
The text was updated successfully, but these errors were encountered: