Slave remote instance stucked in infinite loop

[fpytloun]

Make sure you are running the latest version of Home Assistant before reporting an issue.

You should only file an issue if you found a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum:

Home Assistant release (hass --version):

Master: 0.30.2 (docker image)
Slave: 0.30.2 (all 0.30 series affected)

Python release (python3 --version):

Python 3.4.2

Component/platform:

Remote

Description of problem:

Running slave instance using following script (according to docs):

#!/usr/bin/env python3

import sys
import homeassistant.remote as remote
import homeassistant.config as config
import homeassistant.bootstrap as bootstrap

try:
    config_file = sys.argv[1]
except:
    sys.stderr.write("Usage: %s <config>" % sys.argv[0])
    sys.exit(1)

# Location of the Master API: host, password, port.
# Password and port are optional.
api = remote.API("mylittleserver")
print("Remote API status: %s" % remote.validate_api(api))

# Initialize slave
hass = remote.HomeAssistant(api)

config = config.load_yaml_config_file(config_file)
for component in config.keys():
    print("Loading component %s" % component)
    bootstrap.setup_component(hass, component, config)

hass.start()
hass.block_till_stopped()

Execution is stucked at remote.HomeAssistant(api) in a loop (see traceback bellow)

Master logs:

16-10-22 13:49:20 INFO (CP Server Thread-12) [homeassistant.components.http] Serving /api/ to 192.168.33.133 (auth: True)
16-10-22 13:49:20 INFO (CP Server Thread-11) [homeassistant.components.http] Serving /api/ to 192.168.33.133 (auth: True)
16-10-22 13:49:20 INFO (CP Server Thread-6) [homeassistant.components.http] Serving /api/states to 192.168.33.133 (auth: True)

Expected:

Loop should be started at hass.start(), load configuration first and work fine.

Traceback (if applicable):

Traceback (most recent call last):
  File "/srv/homeassistant/scripts/slave.py", line 20, in <module>
    hass = remote.HomeAssistant(api)
  File "/opt/homeassistant/lib/python3.4/site-packages/homeassistant/remote.py", line 131, in __init__
    self.states = StateMachine(self.bus, self.loop, self.remote_api)
  File "/opt/homeassistant/lib/python3.4/site-packages/homeassistant/remote.py", line 267, in __init__
    bus.listen(ha.EVENT_STATE_CHANGED, self._state_changed_listener)
  File "/opt/homeassistant/lib/python3.4/site-packages/homeassistant/core.py", line 476, in listen
    future.result()
  File "/usr/lib/python3.4/concurrent/futures/_base.py", line 397, in result
    self._condition.wait(timeout)
  File "/usr/lib/python3.4/threading.py", line 290, in wait
    waiter.acquire()

[fpytloun]

Found out that latest working version is 0.28.2

[w1ll1am23]

Having this same issue after upgrading from 0.28.2

[rlobbins]

Currently trying to setup a master/slave configuration. It makes it to about the same point and fails. It looks like it connects to the master, but no components are ever loaded.

[DigitalOSH]

I'm also having this issue

[fpytloun]

Think this may fix the issue but needs at least rebase + author asked for an assistance with fixing tests: #3681

[DigitalOSH]

I may be doing it wrong, but it didn't seem to help. It also didn't make much sense to me. Could you elaborate on it?

[balloob]

I don't have time to look into this issue. There is too much going on and it's just not a priority. From a quick glance at remote.HomeAssistant.start method, it seems like it is not starting the loop.run_forever like core.HomeAssistant.

I am considering deprecating remote.HomeAssistant anyway, it was never extensively developed and is not robust at all. An alternative is to call the API methods available in the remote package or to use MQTT eventstream.

[fpytloun]

I am just curious: am I doing something wrong that I consider having functional slave instances as one of the most important features?
And my use-case is simple - I have one server running hass and multiple Raspberry Pies with sensors and various stuff attached to it. The only workaround how to avoid using hass slaves is probably to use ssh to execute commands remotely to read data from sensors or execute switch, etc. which I don't like very much.

[aequitas]

I also consider remote slaves one of the key features.

[michaelkuty]

I think that @balloob says that for your secondary sensors you would use sensors which could streams events throught MQTT or something else, but if you want working slaves in latest release use my fixes from #3681

[aequitas]

@balloob I'm just starting to get accustomed to HASSS so sorry for my lack of knowledge.

With your suggestion of API methods/MQTT are you suggesting:

• satelites installations that run the HASS stack with components for device integration and communicate with a master through API/MQTT to extent the reach of the master.
• remote nodes without any HASS installation/components but instead 3rd party application that communicate to the HASS 'master' using API/MQTT.

I prefer the former as it allows flexibility for satellite nodes (eg: extra wireless coverage) with the ease of having everything managed/configured in one platform instead of deploying and configuring different applications/integrations.

[rbressers]

For me, creating a modular setup with multiple instances would be a key feature. Right now, i also end up in an infinite loop. Any update on this issue yet?

[GMFalka]

Infinite loop here too. Hoping for some dev-time to fix it.

[oblogic7]

Can confirm that this is still happening on 0.39.2. Any plans for when this is going to be corrected? I would really like to use slave instances. MQTT eventstream is not acceptable in my use case as I need to sync events from multiple slave instances.

[aequitas]

Without further information its hard to determine the source of you issue. Can you please provide (debug) log info, used version (master and slaves) and configuration. Please reduce configuration to the minimal required to replicate the issue.

[oblogic7]

@aequitas See my post here: https://community.home-assistant.io/t/multiple-instances-why-so-difficult/13094

[aequitas]

@oblogic7 sorry I was confused with a different issue I had been working on. I have moved to the MQTT eventstream which also had a looping problem which is solved now. I though your issue was a regression on this.

[oblogic7]

I believe I have found a viable solution for using the eventstream by subscribing to a wildcard topic. I still need to setup my second slave instance to make sure it will work though.

[rbressers]

@oblogic7 if you found a definitive solution, could you please share your configuration? Thanks!

[oblogic7]

I will share as soon as I have the chance to validate that it works as expected.

[vandalon]

Also very curious about you solution :)

[oblogic7]

I was finally able to test my solution that uses MQTT Eventstream and it appears to work for my intended purpose (YMMV).

I have opened a PR to update the MQTT Eventstream docs to demonstrate how to enable multiple instances. home-assistant/home-assistant.io#2230

I'm also working on a video to show this setup in action.

EDIT: Video here: https://www.youtube.com/watch?v=7STM48YG_wY

[vandalon]

This works pretty good, But since sensors from the slave are only showing up on change I can not always see if the garage door for example is closed. I tried working with a binary sensor and a template but it seems remote sensors do not work with that. I try and avoid polling the slave HA, I would rather get it via mqtt or the other HA and leave it on the home page. Do you know any way to get that done? :)

[oblogic7]

I'm still looking for a solution to this. I'm also curious to see if the interface change precludes the sensor from being used as a condition on a rule since it seems that the master instance "forgets" the state.

[n8henrie]

Also just running into this. Should probably remove the hass = remote.HomeAssistant(api) stuff from the docs if it's been broken for months and a fix is low priority.

[MartinHjelmare]

Event forwarding has been deprecated: #6633. MQTT event stream is still there though.

[cmsimike]

Hi - I'm hoping to pick anyone's brain about the MQTT event stream, because I feel like what I'm seeing here is a bug. I have instance A and B setup, with the master/slave config setup from the MQTT event stream docs.

What I'm noticing is while I'm looking at the gui of the slave instance (which only has 1 configured device) eventually all of the devices from my master instance is reflected in the slave gui. However, when I refresh the slave GUI, all the devices disappear again but if I leave the gui open long enough, they all show back up.

This confusion, i think, is making my master/slave setup not hugely useful. for instance, I can manually go into the dev tools of the master instance and turn on a light that is defined in the slave instance (because that is a service call which is pushed to all slave instances), but a scene on the master hass cannot find that light and thus I cannot set this light as part of a scene fired off from the master hass instance.

I guess i kind of understand why I'm seeing this (I am firing an event that both hass instances can respond to if they have the proper entity defined) but I am still a bit confused as to why I'm seeing all devices from master instance A in slave instance B's gui, until i refresh it.

Ideally, any slave hass instance would be effectively a remote hass instance that runs and can push updates to the master instance. For example, I have a lifx bulb in my office that shows up in the slave hass instance. I would love for my master instance to see any device in my office and treat it as if they were local devices.

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍

[balloobbot]

This issue will be auto-closed because there hasn't been any activity for a few months. Feel free to open a new one if you still experience this problem 👍