Orvibo S20 can't be found after system restart

Hello,

I have a strange issue with Orvibo S20 switch.
It was correctly discovered at first and worked very well but after I restarted my whole server on which HomeAssistant is running it simply can’t be discovered. I think it also happened when I killed home assistant daemon and started it again.

Switch has static IP assigned, configuration did not change. Switch works with original Wiwo app.

Here is the log:
15-12-29 21:13:46 homeassistant.components.switch.orvibo: S20 at 192.168.1.53 couldn’t be initialized
Traceback (most recent call last):
File “/usr/local/lib/python3.4/dist-packages/homeassistant/components/switch/orvibo.py”, line 33, in setup_platform
S20(host)))
File “/home/tomek/.homeassistant/lib/orvibo/s20.py”, line 123, in init
(self._mac, self._mac_reversed) = self._discover_mac()
File “/home/tomek/.homeassistant/lib/orvibo/s20.py”, line 165, in _discover_mac
raise S20Exception(“Couldn’t discover {}”.format(self.host))
orvibo.s20.S20Exception: Couldn’t discover 192.168.1.53
15-12-29 21:13:55 homeassistant.components.recorder: Found unfinished sessions

I think that there might be some bug in Orvibo component or it was caused by uncorrectly closed session.

I have found workaround for this issue.

  1. unplug the switch
  2. kill hass daemon (can it be closed in more frendly way? I did not find a restart option in the interface)
  3. Assign new static IP - ones that were previously assigned do not work
  4. Change Switch configuration to new IP in configuration.yaml
  5. Plug the switch and check if it works with Wiwo app
  6. Run hass --daemon

This usually fix the issue but requires a lot of changes and I just can’t simply restart my server and sometimes close and start homeassistant daemon to load a new configuration.

This is odd. Communication is UDP, so there isn’t really a concept of sessions. There may be some lower-level OS caching or handles being left open. There is a potentially-related bug that I’m looking at - maybe that fix will help.

Anyway, I will try to reproduce this and solve.

I did a little more testing.

  • killing hass daemon did not caused the problem
  • restarting whole server did cause the problem
  • restarting router does not help

Only fix is to assign new ip to orvibo switch an start home assistant with new ip in config.
Strange thing I noticed that when this error happens the log is being cleared and it’s the only thing there.
Not sure if it’s related though.

Latest log:
15-12-30 20:37:02 homeassistant.components.switch.orvibo: S20 at 192.168.1.54 couldn’t be initialized
Traceback (most recent call last):
File “/usr/local/lib/python3.4/dist-packages/homeassistant/components/switch/orvibo.py”, line 33, in setup_platform
S20(host)))
File “/home/tomek/.homeassistant/lib/orvibo/s20.py”, line 124, in init
self._subscribe()
File “/home/tomek/.homeassistant/lib/orvibo/s20.py”, line 184, in _subscribe
“No status could be found for {}”.format(self.host))
orvibo.s20.S20Exception: No status could be found for 192.168.1.54

This is all there is in the log file.

Some more details of server:

  • homeassistant version 0.10.1
  • server on Ubuntu 14.04.1
  • kernel Linux 3.13.0-74-generic on i686
  • Python 2.7.8 and 3.4.3

If you need anything more just let me know.

I could not reproduce this.

Try increasing the timeout, just to rule that out …

Edit ~/.homeassistant/lib/orvibo/s20.py, line 16 to this:

TIMEOUT = 5.0

Increasing timeout did not help.
I have also changed discovery timeout to 5.0 but this also did not help

[code]# S20 UDP port
PORT = 10000

UDP best-effort.

RETRIES = 3
TIMEOUT = 5.0
DISCOVERY_TIMEOUT = 5.0

Timeout after which to renew device subscriptions

SUBSCRIPTION_TIMEOUT = 60[/code]

Log after changes still the same.
16-01-01 10:27:26 homeassistant.components.switch.orvibo: S20 at 192.168.1.54 couldn’t be initialized
Traceback (most recent call last):
File “/usr/local/lib/python3.4/dist-packages/homeassistant/components/switch/orvibo.py”, line 33, in setup_platform
S20(host)))
File “/home/tomek/.homeassistant/lib/orvibo/s20.py”, line 123, in init
(self._mac, self._mac_reversed) = self._discover_mac()
File “/home/tomek/.homeassistant/lib/orvibo/s20.py”, line 165, in _discover_mac
raise S20Exception(“Couldn’t discover {}”.format(self.host))
orvibo.s20.S20Exception: Couldn’t discover 192.168.1.54

In my configuration I have blocked internet access for the switch on router so it could not be controled from outside by Wiwo app ( I don’t trust Orvibo much). I have enabled this for testing but it’s still the same. The log is from when switch could be controlled from internet.

I only have the switch for about 2 weeks so far but I noticed the Wiwo app sometimes hangs (this busy circle keeps running around) when I try to control the switch. I need to close app and start again. Usually this helps and I can control the switch from app.

My router is Asus RT-N18U on AsusWRT.

Changed IP from 192.168.1.54 to 192.168.1.50, closed hass, restarted switch to get new ip, changed config and started hass --daemon.
It simply got working again. Rebooted my sever, started hass --daemon (not started at boot), Orvibo doesn’t work.

Any other ideas?

Can you verify that nothing else is using UDP port 10000?

netstat -nulp

You don’t have a firewall on your box or router that could be interfering?

Lastly, in the same file as before: Delete lines 55 and 56:

for opt in [socket.SO_BROADCAST, socket.SO_REUSEADDR, socket.SO_REUSEPORT]: _SOCKET.setsockopt(socket.SOL_SOCKET, opt, 1)

And replace with:

    _SOCKET.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
1 Like

Hi,

I think I know what might be the problem.

Part of netstat log (192.168.1.10 is server):
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
[…]
udp 0 0 192.168.1.10:33000 0.0.0.0:* -
udp 0 0 0.0.0.0:10000 0.0.0.0:* -
udp 0 0 127.0.0.1:38191 0.0.0.0:* 2297/python
[…]

After your changes it shows a bit more:
16-01-01 21:00:02 homeassistant.components.switch: Error while setting up platform orvibo
Traceback (most recent call last):
File “/usr/local/lib/python3.4/dist-packages/homeassistant/helpers/entity_component.py”, line 145, in _setup_platform
self.hass, platform_config, self.add_entities, discovery_info)
File “/usr/local/lib/python3.4/dist-packages/homeassistant/components/switch/orvibo.py”, line 21, in setup_platform
from orvibo.s20 import S20, S20Exception
File “/home/tomek/.homeassistant/lib/orvibo/s20.py”, line 293, in
_setup()
File “/home/tomek/.homeassistant/lib/orvibo/s20.py”, line 57, in _setup
_SOCKET.bind((’’, PORT))
OSError: [Errno 98] Address already in use

I have a webmin running on the server and it’s default port is 10000.
I will change that and will see how it works.
The strange thing is that Webmind uses port 10000 for connecting via TCP/IP cause it’s for webinterface, it’s not a UDP right?
Second strange thing is that it happens only after restart… anyway seems like a system issue and I’ll test it, check and let you know.

Thanks for your help.

1 Like

After changing webmin port in configuration to 10001 netstat shows something like this:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
[…]
udp 0 0 0.0.0.0:34019 0.0.0.0:* -
udp 0 0 0.0.0.0:10000 0.0.0.0:* 3734/python3
udp 0 0 0.0.0.0:10001 0.0.0.0:* -
udp 0 0 0.0.0.0:1900 0.0.0.0:* -
[…]

Strangely, webmin still responds at 192.168.1.10:10000 but the switch seems to be discovered just fine now.

Thanks for your help and it might be worth noting that Webmin can cause such problems.

1 Like

OK, glad we were able to solve it.

1 Like

If anyone reading this and have this problem:
In Webmin you need to change “Listen for broadcasts on UDP port”.
Changing “Listen on IPs and ports” makes no difference.

I’ve seen the same error and don’t use webmin… any other ideas?

I am facing the same problem too and I don’t use webmin (not that I aware off. I don’t even know what it is). This is what I have in the error log…

17-03-10 18:06:23 ERROR (MainThread) [homeassistant.components.switch] Error while setting up platform orvibo
Traceback (most recent call last):
  File "/usr/local/lib/python3.4/dist-packages/homeassistant/helpers/entity_component.py", line 151, in _async_setup_platform
    entity_platform.add_entities, discovery_info
  File "/usr/lib/python3.4/asyncio/futures.py", line 388, in __iter__
    yield self  # This tells Task to wait for completion.
  File "/usr/lib/python3.4/asyncio/tasks.py", line 286, in _wakeup
    value = future.result()
  File "/usr/lib/python3.4/asyncio/futures.py", line 277, in result
    raise self._exception
  File "/usr/lib/python3.4/concurrent/futures/thread.py", line 54, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/local/lib/python3.4/dist-packages/homeassistant/components/switch/orvibo.py", line 37, in setup_platform
    from orvibo.s20 import discover, S20, S20Exception
  File "/home/pi/.homeassistant/deps/orvibo/s20.py", line 314, in <module>
    _setup()
  File "/home/pi/.homeassistant/deps/orvibo/s20.py", line 56, in _setup
    _SOCKET.bind(('', PORT))
OSError: [Errno 98] Address already in use

Please help.

I seem to have lost mine after the latest update to Hass. The strange thing is that even though they aren’t there they are still responding to my existing automations and switch on and off. I didn’t expect they would fire with an unknown entity in the action.

I made a new network a few days ago which is run by a Unifi router and after a few hours of fighting with the switches I set up a separate wifi network for them with lower security as recommended in another thread. After resetting and rebooting a million times I finally got them into hass again. After the upgrade to 43.0 and reboot I can’t see them in the entities list any more and get the following error.

17-04-23 17:23:51 ERROR (MainThread) [homeassistant.components.switch] Error while setting up platform orvibo
Traceback (most recent call last):
  File "/usr/src/app/homeassistant/helpers/entity_component.py", line 155, in _async_setup_platform
    entity_platform.schedule_add_entities, discovery_info
  File "uvloop/future.pyx", line 230, in __iter__ (uvloop/loop.c:110600)
  File "uvloop/future.pyx", line 432, in uvloop.loop.BaseTask._fast_wakeup (uvloop/loop.c:113980)
  File "uvloop/future.pyx", line 101, in uvloop.loop.BaseFuture._result_impl (uvloop/loop.c:108900)
  File "/usr/local/lib/python3.5/concurrent/futures/thread.py", line 55, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/src/app/homeassistant/components/switch/orvibo.py", line 37, in setup_platform
    from orvibo.s20 import discover, S20, S20Exception
  File "/usr/local/lib/python3.5/site-packages/orvibo/s20.py", line 314, in <module>
    _setup()
  File "/usr/local/lib/python3.5/site-packages/orvibo/s20.py", line 56, in _setup
    _SOCKET.bind(('', PORT))
OSError: [Errno 98] Address already in use

netstat -nulp shows
udp 0 0 0.0.0.0:10000 0.0.0.0:* -

But I don’t use webmin and have no idea what that entry is if it isn’t Hass.

Is it possible that the port is being held captive by a previous version of hass? I recently switched to using docker and I think this might be the first version upgrade since but don’t fully understand docker yet so have no idea if this would be relevant. I have also lost z-wave but this isn’t throwing any errors and seems to show up if I delete any zwave related files from my persistent hass directory. (and disappears again on reboot until I delete the files)

Any ideas?

1 Like

+1 here. I now see this “Already in use” error after updating to 0.43 (or I think that’s what’s caused it).
I added the Spotify media player platform, so maybe that’s the change causing this…

I actually removed the new spotify component after trying it out - and a device tracker as they were the only new things in my config and still no go.

@lindsayward

I have just found my problem - it seems my guess about a previous version was correct. I am completely new to docker so take this googling of mine how you will.

I was able to see what docker containers were running by using command:-

docker ps -a

This lists all the containers and their status. In my case I had three home assistant containers - the current one, the current one which I backed up as home-assistant-oldv43.0, and an even older home-assistant-old. The older one showed a status of up 43 hours which was the last time I rebooted. The old43.0 had a status of Exited.

So I exited the old version and restarted the container I wanted to use and my Orvibos and Z-Wave have returned. Yayy!

sudo docker stop home-assistant-old
sudo docker restart home-assistant

I did run sudo docker ps -a in between just to check the container was stopped.

I am not sure if it will restart again on the next reboot but

sudo docker rm home-assistant-old

will remove the container if need be.

Hope this helps your situation. I am looking into using docker compose at the moment as hopefully a way to better track what is going on.

I am not using Docker, but my problem is probably similar, in that I had multiple hass processes running. I’m not sure why that happens - perhaps the service not restarting properly. I’ve had very slow service restarts, so have cancelled that sometimes and then restarted again, which might lead to multiple instances…
I do see my Orvibo device (and no error in log) now.

Glad you got it sorted. My apologies for misunderstanding. I’ll leave it there in case it helps someone else.

You’ll want to remove the old image too.
They take about 1gb each.

Docker images
Docker rmi (image ID)

1 Like

Oh wow, thanks, appreciate the advice - 1.8 GB each! I thought I had deleted them with rm but I guess that was just the container. It seems I have a lot more reading to do.