Roon can see and stream to attached Topping DS10a when Pi/bridge connected via ethernet.
Wifi SSID/password entered/saved on Ropieee admin page. Pi/bridge powered down. Ethernet disconnected. Pi/bridge restarted. Now can connect to Ropieee admin page via wifi.
Roon no longer able to see attached DAC. (Yes, can see that Ropieee DID retain wifi SSID/password.)
If ethernet cable reattached to Pi, Roon can once again see the attached DAC.
Possible clue: in Roon app on iPhone it says “No audio devices found”. BUT if I scroll far right to “About” and click, along with the Core, can also see the “Roon Bridge” with same IP address that when entered in browser opens the Pi/Bridge/Ropieee web pages.
Tried rebooting all devices multiple times – including cable modem, mesh wi-fi network (original Google mesh, not newer one).
I didn’t read the referenced links, but:
What do you see in the “Audio” tab, compare wired and then wireless?
It should be listed there, so you might just have to “Enable” it then to make it available.
DAC was there on audio tab on ethernet. I enabled it. (Rememer, I mentioned I could stream to it on ethernet, which wouldn’t have been possible if not initially enabled.)
On wifi there is nothing on Audio tab – but bridge still present on About tab.
Please remember, if I unplug e-net and reboot pi, NOTHING changes on about tab, but there are no longer any endpoints available – even though still connected.
I know this support community is about Roon/Ropieee, but would appreciate any tips/tricks or references where I can learn what I need to know to get this working.
As @Rugby mentioned, everything needs to be on the same subnet. You have 192.168.68.xxx and 192.168.0.xxx The third octet is different, so those are on different subnets - the question is why are there different subnets?
Your core is on 192.168.0.3, so it can’t connect to the devices with 192.168.86.xxx IP addresses.
I have a cable modem provided by Wow Cable. I have the original Google Wi-Fi mesh network connected via an ethernet cable directly from the back of the cable modem to the first puck.
Yes, I’m actively googling how to force the mesh to share the subnet. No luck yet…
When installing original Google WiFi mesh couple years ago, took the easiest path for blanket coverage. No consequence till now…
Whichever “puck” is connected to cable modem’s built-in router via ethernet becomes first in wireless chain connecting all pucks back to modem – but with a different subnet (if that is correct terminology). Used existing ethernet cable that went through floor from cable modem in basement (near cable company’s underground entry point) to ground floor to provide better coverage on first floor AND outside of home in backyard. Only other hard-wired ethernet connection was “home-run” back to cable modem for full-time, work-from-home office in basement. Everything worked fine – streaming to multiple Roku’s (including 4K HDR for home theatre) and many Chromecasts.
Solution: Google pucks have two ethernet ports. One “input” from cable modem and another “output” for attaching other devices to pucks via ethernet. I didn’t want to pull second ethernet cable between floors – and did NOT need to. To fix Roon/Ropieee, I simply moved ethernet-attached puck down to basement (where my Intel NUC Roon ROCK Core is) and plugged Core’s ethernet cable to puck instead of cable modem.
YAY!!! Now can see all audio devices in apps on every device. Thanks to all who helped, particularly @spockfish. (Donation headed your way soon.)
For those of you who consume techie stuff more easily with a visual, see below. (Change is highlighted in orange.)
Ah, OK. Your diagram makes sense. The Google puck creates a WiFi network with a different subnet. In the first scenario the core and bridges are on different subnets.
In the second, the core gets its IP address from the first puck, which places its IP address on the same subnet as the two bridges.
There should be a way to set the IP address range and subnet that the Google puck gives out to WiFi clients if it’s designed properly…
Then the BEFORE scenario would work, which maximises bandwidth between devices.
Totally agree regarding should be able to specify setting on Google Wifi, and there are lots of menus where things can be set. NOT being network knowledgeable at all, didn’t want to risk breaking everything else already working on wifi. When came across suggested resolution and realized it would leave wifi IP addresses not-mucked-with, I chose that. If I get performance/buffering issues, I may be more incentivized to take some risks and start tweaking.
but stuck at moment. 
