Sure, the ESP32 will connect to whichever mesh node provides the best 2.4 GHz signal
- It monitors CSI from that specific node (the one it's associated with)
- If the ESP32 roams to a different mesh node, it will start monitoring CSI from the new node
The system doesn't care about the router's internal mesh topology, it just needs a stable connection to receive CSI data from the associated access point.
In terms of layout of rooms and useful monitoring, you have to be able to configure which node it attaches to, right? Because it's going to monitor the physical space between itself and that node.
So you might have an ESP32 placed across the room from one mesh node to monitor that particular room. But if that ESP32 roams to, say, the mesh node on the floor above it, it's going to monitoring a much less useful space - just the vertical space between itself and the mesh node on the floor above.
Am I envisioning this correctly? I'm thinking its a problem for systems like eero, where you can't lock a device to a particular mesh node.
On the critical topic of Mesh Routers and Roaming, a possible solution is to force the ESP32 to hook onto the MAC address of a single Access Point, as discussed here:
I absolutely love Arc for Mac. It gets all the little things right -- at least for my workflow and mindset. But "getting all the little things right" in a browser isn't something you can monetize.
What it means, I suspect, is that you should look into the Zen browser for Mac (and Windows and Linux, to boot), which is very clearly heavily Arc-inspired but not aiming for VC Unicorn status.
Neat! I played for a while with my 10yo son. The timer is a bit of a drag. My suggestion is to either implement a lives mechanism like the other poster suggested, or to make the timer reset after each success.
Which is really depressing. Toyota make fantastic vehicles but they're being outclassed by others simply because their infotainment system feels like a relic from the early 2000s.
They've also doubled down on their refusal to not include Carplay/Android Auto. They're putting something called "SmartDeviceLink" which is yet another MirrorLink 1.1 clone (which is itself a disaster), but this time controlled by a different consortium of companies.
Although amusingly the other major auto maker putting SmartDeviceLink in their vehicles, Fort, has already given up and put Carplay/Android Auto into their latest Ford SYNC3 infotainment system software. Leaving Toyota the only major company providing SmartDeviceLink.
I legitimately think Toyota will slump in sales when seemingly every other major manufacturer has Carplay/Android Auto. All because Toyota is greedy and wants to profit off of the infotainment unit rather than the vehicle itself.
They've also doubled down on their refusal to not include Carplay/Android Auto. They're putting something called "SmartDeviceLink" which is yet another MirrorLink 1.1 clone
I just do...not...get this. In what alternate reality do they live that would cause them to think "this time will be different"? History has shown time and again that your proprietary special snowflake platform is not going to cause app writers to flock to you when there's something like CarPlay/Android Auto available. I mean, MirrorLink was a pretty good idea, didn't have any real competitors at the time, and it still sold like dog shit sandwiches. Save everyone some time and money, suck it up, swallow your pride, and just put CarPlay/Android Auto on there. Because as I've said elsewhere in this thread, not only will I not buy your proprietary infotainment system, I won't even buy your car.
Even I, a long-time geek who will endure a lot of pain to get something working, cringes at the thought of the hoops I'd have to jump through to get "SmartDeviceLink" to an even minimally useful state. My CarPlay head unit also has MirrorLink, and while I was waiting for Pioneer to update the firmware to include CarPlay, I thought I'd give MirrorLink a whirl. First, I apparently needed to go get a special cable. Yeah, fuck that, you exceeded my tolerance for friction in the first sentence of your user manual. CarPlay? Plugged my iPhone in, waited to see what Apple's special version of frictional hell would be and...it just worked. There's your competition, car makers, and if takes more than just plugging my phone in I'm not buying it.
* voice commands for navigation actually work. Recognition is quick and accurate.
* Should you need to type in an address, Tesla treats you like an adult, and lets you do it while the car is moving.
All the other recent cars I've driven won't even let the passenger enter an address unless the car is stopped.
Ha yeah - we opened up a port in iptables for this so we don't have to ssh tunnel in to see stats. Obviously, if you're concerned about exposing numbers, you can view via an ssh tunnel instead of opening a port.
Not these guys, but doing realtime viz of signals.
We've switched over to a minimalist canvas renderer--if you don't need interactivity or styling, and instead just "draw me as much as you can as fast as you can, damnit.", we hope it's the way to go.
I've been playing around (http://yield.io) with Flot, which uses canvas and rendering speed seems pretty good, but resizing gets a bit wonky when there are multiple canvas elements on a page.
Yeah, we started with Flotr2...too many graphs on a page (with thousands of datapoints per graph) brings Chrome to its knees, even with auto margins and whatnot turned off.
@angersock That's a good point on the number of points. If I downsampled the yield history to monthly yields, that would probably help the performance.
I will add that if you keep it as two buttons, the colors should be switched. Right now, the active button is black and the other is gray. But gray buttons say to me that they are disabled, so it looks like I can only hit the play button when it's already playing.
Have you thought of writing the metrics collection part (and eventually the whole thing) in Go? You would get the stand-alone distribution right away and would keep people from installing any extra dependencies.
We've clocked the CPU usage of the scout_realtime daemon at 1% on an Intel Xeon 2.40GHz CPU. Memory usage is around 22 MB. If you turn off the metric collection (by clicking the pause button on the web page), CPU usage will effectively drop to 0%, and you'll still be able to visit the web page and re-enable metrics at any time.
It's always instantly clear when something like iTunes or a Chrome helper starts eating up 105% CPU, and provides quick access to force quitting it. :)
