1_2__4
Joined 9 years ago
Joined 9 years ago
This isn't high school, and you're not going to give me homework just for the chance to work for you. And I use the homework analogy intentionally, because just like with school, this doesn't scale. I can't interview at, say, 10+ companies all of whom are expecting me to put in paying-employee-level work just for the interview while also holding down my regular job. And I'm not going to go with a significantly shortened list of candidate companies just because their interview process is so onerous that I literally don't have the time to talk to more.
Again, I know not everyone can do this, but realize that companies try to exploit you during the interview phase, too. You need to also have standards for what you're willing to put up with.
The way I implemented it was to have each beacon transmit on I think 1s (might have been 5s to save power) intervals, and some python code on an RPI that listens for them, with a timeout for each. If the listener gets a ping it immediately forwards it to mqtt as a "home" ping, using the beacon id to set the topic. If it doesn't get a ping within the timeout then the rpi generates and sends an "away" mqtt message for that beacon. My expectation was to have it alert me within ~2-3 minutes of a vehicle going from "home" to "away". In practice:
- BLE beacons aren't very popular really, most of them are made by small foreign companies who don't sell them in places like Amazon. The ones Amazon does sell are kind of crappy. Setting them up usually involves downloading a vaguely-sketchy app to your phone (I haven't figured out how to configure them from the rpi). They all seem kind of janky honestly.
- Bluetooth and Wifi use the same (some) hardware on an rpi, meaning if you start rapidly scanning for BLE tokens your wifi performance will drop to the point of the rpi being unusable (ssh sessions timing out). I fixed this by buying a separate USB bluetooth dongle, although even that was a pain to get working in the pybluez module - in general bluetooth under linux along with the python bindings are finicky and crap out easily, it seems.
- I have my dmesg and syslog spammed with "Bluetooth: hci0: advertising data len corrected" when using bluetooth scanning, I managed to find a couple bug references to it and other people complaining about it but no fixes over multiple system updates.
- It's just... Not reliable. I don't know why. I've tried really hard to make it reliable, and maybe the problem is the RPI-as-bluetooth (maybe if I used a microcontroller as the receiver it would work better?), but I've tried all variations of scanning windows and such and dug down into the code for Bluez without figuring out either what I'm doing wrong or where the issue is. Beacons will supposedly not ping for minutes at a time despite being on a 5s interval no matter what I do, and this is for beacons maybe 6 feet from the receiver (although ones further away do timeout more).
The last thing is what finally killed the project for me. I had it (still have it) all setup in HA with notifications and schedules and such, but I just turned off all the automation for it until I get a chance to tear it down. Failed experiment.
The whole article is extremely thin on facts and very fat on speculation and breathless rhetoric.
And I'd further counter that: yeah, actually, you and your company ARE special. Every company is. There is no One True Way of running a business, or any individual aspect of that business. Everyone's triangulating around resources, people, industry, corporate vision, etc. If anything I'd say the argument that "you are not special" is the fallacy, as it leads directly to the kind of cargo-culting that you see so many failed companies do.
Finally, when we see successful companies, how often is it because they just mimicked what everyone else was doing? Not very frequently, as it turns out. Well-behaved companies seldom make history.