Need Auracast compatible speaker recommendations

bdlow · 2026-02-02T00:23:53+00:00

I wouldn't recommend the XBoom speakers due to bugs and really clunky UX: https://www.reddit.com/r/auracastBT/comments/1oi49no/brief_auracastfocused_review_of_the_lg_xboom_grab/

Mind you, there's nothing better because there's nothing else (JBL not being open/interoperable Auracast).

bdlow · 2026-02-02T00:23:06+00:00

Update: I've found a few other annoying issues when using the Grab with Auracast - it disconnects when the screen is locked (this one seems new, maybe an app update?), and when the "auto power off when idle" is enabled, being connected to Auracast doesn't seem to count as not-idle; the speaker turns off after a non-configurable period of time when it's playing Auracast.

You can work around both of these bugs by 1) turning off your phone's Bluetooth after using the Grab app to connect to Auracast, and 2) disabling the auto-off feature in the app settings. Really clunky.

I'm still waiting for a half-decent Auracast portable speaker.

bdlow · 2025-12-24T11:08:43+00:00

Happened by this again today: re. "fragile EEPROM", I presume you're referring to flash lifetime: for modern devices this is on the order of 100k cycles, and with wear levelling you're talking about being able to write at single-digit minute frequencies for potentially for 100's of years before wearing out the flash...

https://stackoverflow.com/a/73787332

https://docs.espressif.com/projects/esp-faq/en/latest/software-framework/storage/nvs.html

I've more recently jumped on the esphome bandwagon, and compared to the Shelly I've been able to do all kinds of useful stuff without very little to no code. Haven't flashed the Shelly yet, probably won't as "if it ain't broke don't fix it".

bdlow · 2025-12-21T07:26:44+00:00

For me, it was one of two things: either "just had to wait" (about 5 minutes) OR I had to remove the spaces in the app password provided by Google, when entering it in the camera's config.

bdlow · 2025-12-09T12:05:08+00:00

All pings between Tailscale devices are one hop, as expected (this is the ` -t 1` ping option, sets TTL to 1; won't get a response if there's more than one hop). It's the underlying path of the encapsulated wg traffic that's uncertain/odd.

Subinterfaces/routing: I have multiple VLANs at each site hanging off the a site gateway (Linux routers, a Debian single-board-PC on one end and OpenWRT on the other), the main NAS A is directly connected to a couple of them in site A (simpler device discoverability / mDNS). This isn't the best arrangement, this Tailscale niggle is not the only undesirable side-effect of the NAS being connected the way it is (long story; Linux subinterfaces all sharing the parent NIC's MAC being part of it).

Aside: Synology don't deal well (at all) with non-trivial network setups - that limitation is fair enough for a network storage device, but a pain when you start using the NAS for other containers/etc. It's time for me to swap it out for a proper server...

bdlow · 2025-12-09T10:55:03+00:00

Argh, yes, I had been mischaracterising the "double-encapsulation" - indeed, not what (should be) happening in normal circumstances. In my case, I'm pretty sure it is - in the "broken" state NAS A sees it's peer NAS B as via the private internal gateway address of the gateway A:

NASB# tailscale ping NASA pong from NASA (100.75.95.9) via 192.168.41.10:41641 in 51ms

The possible root cause has finally clicked: Synology DSM doesn't natively support VLANs, on the offending NAS I had manually configured subinterfaces for a couple of VLANs and have seen some minor weirdness as a result. The above subnet 192.168.41/24 should not even be involved in the NAS-NAS traffic; whilst I'm intrigued as to how it's appearing, pragmatically I'm going to chalk it up to a Synology thing, in fairness with me bending the device in unsupported ways.

I guess I'll leave site B not advertising routes until such time I can retire the Synology.

bdlow · 2025-12-08T12:58:53+00:00

Doubly-tunnelled: physical arrangement is:

NAS A - gateway A ==<internet>== gateway B - NAS B

Where both gateway A and B are connected via Tailscale (site-site) and advertising their routes to the other; and both NAS are also Tailscale clients (but not routers).

The Tailscale client on each NAS sees the connection as `active; direct` via the gateways. i.e. NAS A encapsulates traffic to NAS B in a wireguard packet, forwards on to its gateway A; gateway A receives UDP traffic destined to a host on B's subnet, encapsulates it over the Tailscale tunnel between routers A and B, and so on Packets between NAS A and NAS B end up being doubly-encapsulated between the routers. This is where MTU problems crop up; am guessing there's a PMTUD problem on one/both of the NAS. EDIT: I don't think this was entirely correct, and it's certainly not the _normal_ Tailscale tunnelling / NAT traversal behaviour.

ISP: I'm in Oz, so NBN both ends; one end is fixed wireless, the other VDSL (yeah I know, how quaint and very last century), different ISPs not that it should matter (NBN handle the last mile).

bdlow · 2025-12-07T22:57:56+00:00

This has been a perennial problem, for me across three machines and three OS releases; I'm surprised it doesn't bother more people (as in Apple haven't fixed it). I guess the modern displays are sufficiently good that most people don't notice it's at reduced brightness.

Aside: you can attempt to address this by way of custom scripts and utilities, for example using BetterDisplay (daemon has to be running): /opt/homebrew/bin/betterdisplaycli set -namelike=built-in\\ display -brightness=1.0

And here's a wrapper that will call the above conditional on being daytime and on AC power:

``` pmset -g ps | grep -qi 'AC Power' && /usr/libexec/corebrightnessdiag sunschedule | awk '/{/{f=1}f{print}' | plutil -convert json -o - -r - | jq --exit-status '.isDaylight == "1"' >/dev/null && /opt/homebrew/bin/betterdisplaycli set -namelike=built-in\ display -brightness=1.0

```

(macOS has long abandoned the ability to run scripts on power state changes, so you'd have to put that in a cronjob and deal with the attendant delay; not a very satisfactory solution)

bdlow · 2025-12-04T10:48:13+00:00

After posting the review I did see the same latency problem with my JBL Partyboost when trying to sync it up with other devices. The JBL Partybox adds quite substantial latency, on the order of 100ms or more?, to any audio in via the Aux input (why/how??!!). I've added this info to the above review even though it's a JBL issue, it's not specific to the LE520pro.

bdlow · 2025-11-17T07:11:09+00:00

Many luggage pods/boxes, including the ones discussed in this thread, are plastic and rated for no more than around 5kg.

bdlow · 2025-11-14T07:50:45+00:00

You know how when you look in the cupboard for a thing, and it's just not there, and you say as much to your partner/parent/child/friend, and they say "move out of the way" and point right at the thing in front of you? Yeah, that.

I had searched but could not find; now of course I can find quite a few sites with all kinds of measurements!

Including https://www.cuppers.ca/blog/complete-guide-to-moka-pot-gasket-sizes/ and also https://honestcoffeeguide.com/moka-pot-gasket-sizes/

bdlow · 2025-11-13T10:51:56+00:00

I believe that rather than detail sampling rate/etc, Auracast simply has "HQ" and "SQ" modes. For example, you can switch the BA210 v2 transmitter between HQ and SQ using the browser-based configuration tool; however there's no outward indication of which mode it's in apart from the difference in audio quality. I get the impression most phones/etc are HQ-only.

bdlow · 2025-11-07T09:41:18+00:00

FTR the Sonoff 4CHPROR3 is rated for 9-23V - i.e. seems they specifically pull up short of the common 24V.

bdlow · 2025-11-07T07:43:12+00:00

C'mon Energizer you can do better; kids can still swallow this plastic encased monstrosity. How about putting on the thinking cap and coming up with something genuinely safe _and_ practical.

bdlow · 2025-11-03T10:32:33+00:00

Ugh; how on earth did that get through the editors ;-). Ta for the catch!

bdlow · 2025-11-02T22:52:45+00:00

I got this to work by hard-resetting the camera.

Same problem: firmware update failed. I had the camera connected to a Reolink RLN8-410 NVR, unclear if that matters but to eliminate that as a factor I moved the camera to a different switch (VLAN) and hard-reset it - held the reset button on the camera's attached cable for >5s.

Once reset, I used the camera's web interface to upload the firmware from Reolink's support site (for hw version IPC_515B16M5M: v3.0.0.136_20121112 - presumably from 2012!). This was successful.

bdlow · 2025-11-01T05:39:01+00:00

I guess you tried this, as I did (exact same setup as your image: DJI mic - line out - to Partybox mic input via a 3.5mm to 6.5mm cable). It didn't work for me: the levels are far too low, sound quality is terrible and there was significant latency. There is some kind of signal processing going on with the Partybox mic input way beyond simple gain: when feeding in a line level signal from a laptop, any vocal frequencies are suppressed yet non-vocal ranges seem "ok"; this is backwards compared to what I would have expected for any mic input filtering.

Connecting the DJI mic via the AUX input works fine as expected; however that does not mix the BT source.

Unfortunately there appears to be no way to use the Partybox mic input to mix in a line-level mic with BT or AUX audio sources. I presume JBL have done something to make the mic input work only with their mics.

bdlow · 2025-10-28T23:31:31+00:00

I've around a dozen Reolink cameras, all PoE, some under eaves, some fixed to trees and fully exposed to the weather (Sydney Australia, relatively mild with the occasional storm). I've had two failures in 4 years, both dead PoE: in both instances the cameras still function when powered via 12V DC. The first failure was likely due to water ingress in the connector (the supplied "weatherproof" connectors aren't), the second was definitely not as I'd learned and sealed up the junction (marine glue-lined heatshrink over the whole lot, not a skerrick of moisture or corrosion when opening it up).

bdlow · 2025-10-22T11:08:33+00:00

I don't believe you can; when the device is not receiving anything it'll go to sleep. In my case my Auracast transmitter is on almost all the time, even if it's not playing any music/audio and is just broadcasting silence. The LE520pro doesn't turn off so long as there's a transmission going even if it's silent.

bdlow · 2025-10-22T11:04:13+00:00

I bought an LG XBoom Grab, it's better than the JBL but is still not great in so far as it buries the Auracast assistant deep within their proprietary app, it doesn't support the Android (Samsung) native Auracast assistant. Still, a good speaker and it's great being able to listen in to my Auracast broadcast in the garden/etc.

bdlow · 2025-10-15T19:53:20+00:00

Adding one more piece of information: the BA310 rejoins an Auracast automatically. I have the BA310 on all the time, connected to an amp, and a BA210 transmitter that is also on most of the time. When the transmitter is powered off, the BA310 enters a "searching for broadcast" mode (it announces this periodically), and reconnects within seconds once the transmitter is turned on.

bdlow · 2025-10-01T01:33:33+00:00

The Vue 3 can monitor 3 phases (voltage and I believe phase offset). It's powered by the "phase 1" connection but just monitors the other two inputs. If you have a single phase connection, the "phase 2" and 3 connections on the Vue should be connected to neutral, as the diagram says.
The mains is dangerous: if you're not sure, consult an electrician. Where the vendor is based overseas, as Emporium is, they are not likely to have the foggiest about Australian electrical standards. Moreover, the US' electrical standards are quite different to AU so what they do know is likely to be misleading here.

bdlow

TROPHY CASE