There are a plethora of devices that outperform RPI in every single aspect. This has always been the case, AI proliferation or not. See the top comments in this thread for examples.
Story: I spent roughly 140 USD and a 20 hours or so integrating RPI 5 2g into my vehicle ODB2/12v system. Programming the PID data from ODB2 into something readable on the RPI is something I never want to do again, and the power issues on RPI (and, lack of support) have made it largely not worth it. Further, I thought I would come up with some use case to use the GPIO pins, (IE a hat for "mechanical" GPS, G force, etc.) but the headaches with power, programming and even the touchscreens I procured have made it not worth it.
I am now working on a basic NUC to replace that and it's a dream in comparison and cost next to nothing. GPIO access on RPI is negated as a "feature" by simply using USB on a NUC or similar mini pc for the same.
The energy requirements for growing cotton being largely the sun, and a resource which makes up most of the universe (yes, I know water is several steps from hydrogen). ((And the tangentials like the fertilizers, dieslel etc.))
Compared to the energy requirements of petroleum based products: Incredible density and pressure acting on sufficient organic matter(thousands of times greater than growing cotton), on millenium time scales, then requiring several incredibly expensive and commoditization refining/distribution practices, and the end product is then ceremoniously burned off as poison or discarded into the aether.
It is 100 percent the "gotcha OP thought it is". However I do see/realize the fallacy you're pointing out in that the lesser of two evils is still evil.
I think the main point is that this post is not a good faith attempt to convince people otherwise. It's a shoddly researched opinion piece that has little to no merit as it ignores the complexities of producing either item.
I'm currently integrating one for simple diagnostic readouts to integrated small touchscreen. The main goal being a retro looking display that mainly dumps ODB data/monitors, but also reads maps data to show a "waypointer" a la crazy taxi. (This is proving difficult)
Respectfully, I don't think this is....real?
-I mean, getting the absolute basic bits like diag codes converted from the odb 2 data to some program w/ a graphic interface is about as far as people get, if they can get passed the power and power on/off conundrums.
-If you get that far, How in the lord's name did you manage to seemingly....MITM the vehicles cloud service (climate/locks/remote start) using raspian or whatever? IE; how are you able to establish a TLS connection (yeah, like that lingo?) from the raspberry to the manufacturer API? I think the manufacturer would be interested, as you have functionaley made another key to the car.
-A more important question....what purpose does this serve? IE; the cloud connection/controller is in the car. I can't imagine it's easier to connect to the rasp shell (is it on 24/7?) to connect to the car app to turn on the ac.
- I assume you have one of the "big boy" ones with more WAM. THat said.....are you implying by saying "the pie can actually run qwen" that you are running it locally? if so.....erm...I need reciepts. Cuz idk what that even means nowadays.
Maybe i'm just jaded because my "crazy, crazy taxi style waymarker + ODB2" monitor isn't progressing, but this is...fishy
I've had many drives with the carwatch and the list of verified features is long. Today we tested manufacturer cloud integration for lots of data and e g door locking through it. V0.3 came out today, progress is rapid.
I have no idea on OP, but as far as a waypointer, have been in the area of building bespoke automotive telemetry solutions for a while now (including reversing some existing tools), I would wager that something like the Freematics One+ could do it easily if you combine the IMU with the GPS data (I've managed to get good data for something similar this way). The Freematics dongle does suck in comparison to even the now gone STN2120 as it artificially bottlenecks PID data retrieval on the CAN by the boneheaded design of the STM32 coprocessor firmware, but it probably would work well for your use case.
EDIT: I've actually got a couple cars with the One+ B, doing that sort analysis/data capture, so speaking from actual experience here.
Yes Qwen runs local. Manufacturer cloud workw via existing integrations (they have many) in Home Assistant. The Pi makes a secure tunnel to my home assistant running on a Mac mini at home, and then reads data and gives commands like the manufacturer's mobile app does.
It's all in the repo and this feature has been proven on several test drives, feel free to check it out. What would be great if you can add your cars cloud to your HA and use it with CarWatch, so we could have expand device coverage. I have only 2 cars and they are both MB - the nice thing is you can view both cars on CarWatch, one just does not have OBD port on :)
It's not just power, if it where, they'd fit a USB C rechargable cell in there.
Its still a cheap casio resin watch at the end of the day. If this where to be able to push/pull notifications, the watch would be completely different in cost, ui, marketing, etc.
It would go from being charming retro tech with modern features, to dime a dozen bloatware/fitness tracking hardware.
Of all the things "smart watches" do, the one thing beyond time that most people actually perceive daily is their tracked steps.
IE; My apple watch ais the only one that goes out of it's way to make sure I know my steps for the day, and is always "accurate". Which is nice, but gimmicky for someone like me who doesn't analyze my steps.
I imagine Casio went after similar low hanging fruit, as an acceleromater is cheap/old tech, while still being able to feature compete with something like an apple watch.
Sure, but we can't do sleep tracking well. Todays devices mostly guess and map to typical patterns. Might, might not, work reasonably for you. But chances are that if you want to track your sleep because you suspect irregularities then they are about as useful as a potato.
From other anectdata the apple watch seems to just as bad as everything else.
We just don't seem to have any idea how to track sleep quality even with better devices than just a watch/whatever. Even a binary, is the person I'm attached to sleeping, is hit and miss. And with that in mind you can be pretty sure that the sleep stages etc is even worse.
If you where to start gaming again (at least, as the current vendors intend) you'd find that the bugs you had to account for in the 80s have been (generally speaking) resolved as a byproduct of the DRM/Cloud streaming propagation we're all complaining about.
IE; consolidation of vendors, locking down the way a game propagates, restricting the lifetime of a game, made it "easier" to play games the absolute one way the vendor intends. This gives them the excuse of "Well, we designed the game to be played via perpetual license through only this platform, we can't support or claim responsibility anywhere else".
Which is to say, your comment made me think that the reason the industry is the way it is isn't because money/lawyers, but more because some product managers decades ago began pushing for consolidating/defining video game lifecycles.
It certainly is helpful to understand the mindset of a person who:
a.) their hobby is to play competitive games which mandate kernel level (or similar intrusive anti-cheat)
b.) either accepts the requirements or builds sufficient security gapping to make it a nonconsideration.
These people exist, and would say in an honest assesmment that the above behavior is no more rights-intrusive than what 99 percent of the tech absorbing population allow today.
Exactly, those people are installing Windows in the first place, it's already an entire spyware OS. It doesn't matter cause they pretty much only use it only for games.
Gosh that one got me good. I haven't had a genuine chuckle from a post on here in ages, nevermind one that's from a a CEO of a multibillion dollar firm, who's presentation I was up until that point more or less agreeing with.
IE; It went from "ya know, this is actual a reasonable take to provide investors from a 70+ y/o CEO" to "Goose value 0?"
Story: I spent roughly 140 USD and a 20 hours or so integrating RPI 5 2g into my vehicle ODB2/12v system. Programming the PID data from ODB2 into something readable on the RPI is something I never want to do again, and the power issues on RPI (and, lack of support) have made it largely not worth it. Further, I thought I would come up with some use case to use the GPIO pins, (IE a hat for "mechanical" GPS, G force, etc.) but the headaches with power, programming and even the touchscreens I procured have made it not worth it.
I am now working on a basic NUC to replace that and it's a dream in comparison and cost next to nothing. GPIO access on RPI is negated as a "feature" by simply using USB on a NUC or similar mini pc for the same.
reply