No route to host after a few minutes

I’ve got my particle2 hooked up over wifi and initially I can connect to it just fine from brewpi. However after a few minutes, I get an error:

Could not open port socket://192.168.17.176:6666: [Errno 113] No route to host

For the first few minutes when all is well, In the log I see:

Found BrewPi v0.5.2 build 0.5.2-0-g72e633171, running on a Particle Photon with a V2 shield on port socket://192.168.17.176:6666

Fing gives port 6666 as being visible on the device. After a few minutes (variable, but between 2 and 10 mins), Fing still sees the device, but no ports are visible when scanned.

The device is on fridge constant mode and operates fine - the IP address is also visible on the screen and the status light is green.

If I turn the device off/on, things start to work again. The wifi has a strong signal and I’d like to get this working rather than going back to a cable connected rig.

Thoughts much appreciated

This seems to be a bug in the particle firmware. I reported it here:

It seems to happen less on our latest release candidate, so you can try updating to 0.5.3-rc.2.
But it still happens and I am trying to find a workaround soon.

I think I have found the cause: WiFi channel switching.

On your router, do you have the WiFi Channel set to automatic? Can you try changing it to a fixed value?

The router the device is connecting too has a fixed channel (6) and has a width of 40MHz set. There is another router in the house which this unit doesn’t connect to which has an automatic channel. I’ll change that to be a fixed one, upgrade the firmware to the one in your list and report back…

1 Like

I have put a new release candidate online, which includes a workaround for a bug I discovered in the particle firmware.

Please update with:

python flashDfu.py --tag=0.5.3-rc.3 --noreset --autodfu

@rbpalmer Can you test if this solves the issues with roaming between 2 access points too?

Hi Elco,

I have also installed BrewPi within Docker (Windows 10 Home) in combination with wifi (firmware 0.5.2). Everything works fine. A couple of questions:

  1. Do I have to upgrade to firmware version 0.5.3-rc3?
  2. How can I upgrade to this version within Docker? Do I have to connect via USB or can I update over wifi? Can I use the “updater.py” script or is DFU required? Can you perhaps rewrite the instructions on wiki.brewpi.com? I do not completely understand these instructions; especially the paragraph “Updating system firmware with DFU”.

Thank you for your time and efforts.

1 Like

@elco, Happy to test this have a questions below.

  1. I only have wifi access between the Photon from the docker ubuntu and the V3, do I just run the command and it will work or do I have to put the V3 in DFU mode, (hold setup and press reset the wait for flashing yellow)?

I tried this too, but I’m not sure if the firmware has correctly been applied.

I connected via the USB port just to make sure I had a reliable connection. Brewpi connected fine with this and the USB port was plugged in before I created and started the container. The end of dmesg shows the ttyACM0 device just fine.

What see is:

Will try to download release '0.5.3-rc.3’
Will automatically reboot newly detected photons into DFU mode
dfu-util version 0.8 found installed on system.
Detecting DFU devices
dfu-util: unable to initialize libusb: -99

Did not find any DFU devices.
Is your Photon or Spark Core running in DFU mode (blinking yellow)?
Waiting until a DFU device is connected…
Found new serial port connected: (’/dev/ttyACM0’, ‘Particle Photon’)
Putting Particle Photon in DFU mode
dfu-util: unable to initialize libusb: -99

the unable to initilaize statement then just repeats endlessly. The brewpi has a white screen and the status light has a rappidly flashing green.

If I disconnect the USB cable and restart the brewpi, the front screen shows 0.5.3-rc2, so I don’t think that worked. If I try running a regular updateFirmware the brewpi is recognised and the rc2 version displayed.

Is there a better way to flash tc3?

I updated using the web interface and I may well have made things worse. After updating the connection times out and when I restarted the spark V2 I get a white screen. I tried to get into DFU mode by holding a pin in reset and then applying power. I held the reset pin down for about 5 secs without any lights being displayed. On releasing the reset, I got green, then blue and finally a red/blue light combination while gradually cycle round an increase and decrease in intensity. I’m happy to go back to an empty config as it’ easy to do, but I seem to have bricked the spark 2!!

Over Serial

This will only work if your controller is already running BrewPi and working normally.
In portainer, go to the console of your container.
Run:

python utils/updateFirmware.py --beta

Over DFU

I see I need to look into the DFU process and rewrite it.
The issue comes from the fact that a new container can only use USB devices that are present on the host when it starts. If the spark switches to DFU mode after the container was started, the container does not have access.

If you have a docker setup, you need to update from a temporary privileged container.
On the docker host, run:

docker run -it --name brewpi-dfu --privileged -v ~/brewpi-data:/data --rm brewpi/brewpi-raspbian sudo python utils/flashDfu.py --tag=0.5.3-rc.3 --noreset --autodfu

The first time this will fail, but it will put the device in DFU mode. Exit with ctrl-C.
Then run it again.

I have updated the instructions on the wiki:
https://wiki.brewpi.com/getting-started/updating#updating-an-existing-brewpi-servercontainer

@Elco

I think I have managed to upgrade I see this version now when starting

Aug 22 2017 19:59:55 Found BrewPi v0.5.3 build 0.5.1-13-g51f7941f1, running on a Particle p1 with a V3 shield on port /dev/ttyACM0

Is this correct?

If so i’ll try the fail over testing on the wifi

Rich

Quick update, If this is now on the latest test version,

The fail over of wi-fi Ap now does not reboot/panic the V3 but it still refuses a new connection.

The following hapens until you reboot the V3, on the V3 screen the IP address is 0.0.0.0 if this helps. that is until the reboot, I have set a DHCP reservation for this V3.

Aug 22 2017 20:33:17 Serial Error: read failed: [Errno 104] Connection reset by peer)
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
Aug 22 2017 20:33:17 Lost serial connection. Error: Could not open port socket://192.168.0.240:6666?logging=debug: [Errno 111] Connection refused)
Terminating due to fatal serial error
Aug 22 2017 20:33:47 Notification: Script started for beer 'Cellar-05'
Aug 22 2017 20:33:47 Connecting to controller...
Aug 22 2017 20:33:47 Opening serial port
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
Aug 22 2017 20:33:57 Errors while opening serial port: 
Could not open port socket://192.168.0.240:6666?logging=debug: [Errno 111] Connection refused

Aug 22 2017 20:34:28 Notification: Script started for beer 'Cellar-05'
Aug 22 2017 20:34:28 Connecting to controller...
Aug 22 2017 20:34:28 Opening serial port
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
Aug 22 2017 20:34:38 Errors while opening serial port: 
Could not open port socket://192.168.0.240:6666?logging=debug: [Errno 111] Connection refused

Aug 22 2017 20:35:08 Notification: Script started for beer 'Cellar-05'
Aug 22 2017 20:35:08 Connecting to controller...
Aug 22 2017 20:35:08 Opening serial port
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
DEBUG:pySerial.socket:enabled logging
Aug 22 2017 20:35:18 Errors while opening serial port: 
Could not open port socket://192.168.0.240:6666?logging=debug: [Errno 111] Connection refused

I don’t think you have updated successfully. It should say:

Found BrewPi v0.5.3-rc.3 build 0.5.3-rc.3-0-g83c854f28

Ok I’ll try again later and post the results so you can see if there is any issues.

seems to have taken this time, i’ll give the wifi test a go.

Aug 23 2017 19:18:14 Found BrewPi v0.5.3-rc.3 build 0.5.3-rc.3-0-g83c854f28, running on a Particle p1 with a V3 shield on port socket://192.168.0.240:6666?logging=debug

Woohoo, that seems to have made a big difference. As you can see I rebooted one of the AP’s to make it failover and it lost connection but recovered straight away. (within 30 secs).

And it failed back 10 mins later with no outage as the wifi was not cut off.

``
INFO:pySerial.socket:ignored port configuration change
INFO:pySerial.socket:ignored port configuration change
Aug 23 2017 19:23:07 Error: controller is not responding anymore. Exiting script.

Aug 23 2017 19:23:37 Notification: Script started for beer 'Cellar-06’
Aug 23 2017 19:23:37 Connecting to controller…
Aug 23 2017 19:23:37 Opening serial port
DEBUG:pySerial.socket:enabled logging
INFO:pySerial.socket:ignored port configuration change
INFO:pySerial.socket:ignored _update_dtr_state(True)
INFO:pySerial.socket:ignored _update_rts_state(True)
INFO:pySerial.socket:ignored reset_output_buffer
INFO:pySerial.socket:ignored reset_output_buffer
Aug 23 2017 19:23:37 Checking software version on controller…
INFO:pySerial.socket:ignored port configuration change
INFO:pySerial.socket:ignored reset_output_buffer
INFO:pySerial.socket:ignored port configuration change
Aug 23 2017 19:23:37 Found BrewPi v0.5.3-rc.3 build 0.5.3-rc.3-0-g83c854f28, running on a Particle p1 with a V3 shield on port socket://192.168.0.240:6666?logging=debug

INFO:pySerial.socket:ignored port configuration change

1 Like

I upgraded mine this evening as well. I was not able to update over serial, but the docker dfu method worked (running 2x). Mine was dropping off Wi-Fi between 1-3 days on RC2, will let you know how it behaves on RC3.

I’ve now upgraded the firmware and moved the router to make sure the signal stays up/strong. Things have improved a bit, but not a huge amount. I get about 15 to 45 min worth of access. (previously it was about 5-15 mins) Here is the log of a typical session log taken just now. When this issue happens, the IP address no longer appears on the brewpi screen. Restart the unit with a power off/on and it picks up the same statically allocated IP address as always and the connection is re-established. Other devices in the same physically area are fine and the brewpi continues to control the fermentation OK in fridge constant mode. I’m happy to make any other changes suggested.

Aug 28 2017 13:13:53 Opening serial port
Aug 28 2017 13:14:12 Checking software version on controller…
Aug 28 2017 13:14:12 Found BrewPi v0.5.3-rc.3 build 0.5.3-rc.3-0-g83c854f28, running on a Particle Photon with a V2 shield on port socket://192.168.17.176:6666

Aug 28 2017 14:01:56 Error: controller is not responding anymore. Exiting script.
Aug 28 2017 14:02:28 Notification: Script started for beer '2nd’
Aug 28 2017 14:02:28 Connecting to controller…
Aug 28 2017 14:02:28 Opening serial port
Aug 28 2017 14:03:00 Errors while opening serial port:
Could not open port socket://192.168.17.176:6666: [Errno 113] No route to host

Aug 28 2017 14:03:34 Notification: Script started for beer '2nd’
Aug 28 2017 14:03:34 Connecting to controller…
Aug 28 2017 14:03:34 Opening serial port

Thanks David. I have opened a bug report at Particle that hopefully addresses this.