If you’ve got an IKEA Bekant sit/stand desk and are interested in this sort of thing then Megadesk[1] and Megadesk Companion[2] will allow it to connect to Home Assistant for automation (and also adds memory states).
(This post emphatically not endorsed by my employer.)
Hehe, you're not the first person to have suggested this, and I was wondering how quickly the HN crowd would find and point it out. You're definitely right, but to explain why it is the way it is right now:
* I just didn't want to mess about with postman or curl or whatever in order to test, much easier to just issue a get request by visiting a url in the browser
* I'm going to be ripping the HTTP support out shortly and replacing it with MQTT support so it can more cleanly integrate with my HomeAssistant setup. The HTTP stuff was mostly just the fastest way I could get something approximating what I was looking for.
I definitely agree though, this being a `GET` request is offensive :P
When I'm making a throwaway interface like this, I write the GET handler to return a super-minimal page with an unstyled form having method=POST and the couple of inputs required. The POST handler actions the request and redirects to itself to GET the form again - browsers are so forgiving of incomplete/incorrect markup and the base browser style-sheet screams "this is a prototype, don't judge it!" to anybody you show it to.
To be clear I'm just talking about the web interface, not implying the whole project is throwaway - on the contrary it looks like a lot of work (and a lot of fun :) ) kudos!
POST requests should be idempotent, ideally. PUT requests certainly must be; it's their defining characteristic. GET requests, though, just shouldn't have side-effects at all.
(A /toggle URL isn't idempotent. If it were /open and /close it would be, but still shouldn't be GET.)
Yeah I think people are saying "GET shouldn't change state" and using idempotent incorrectly (which is more "hitting this multiple times shouldn't change things more than once").
Warning, inane tangential commentary: I love the author's "But why?" article. However, I have a worry: So many "But why?" questions in the software world apply to IoT projects, and IoT is playing a central role in the rise of global dystopian surveillance and data-brokering. Sometimes it feels like we're getting too much practice at making this stuff. As though we should be answering "But why?" for more minimal or freedom-promoting projects, like unconnected solar-powered desktops or very dumb sensors and timers for decidedly not-smart homes. I dunno. Just a thought.
You make a good point - but let's be careful to not confuse personal hackery with random internet connected shit you buy from the internet. In my ideal world, every IoT product would directly and clearly document it's hardware, along with allowing the user to replace the firmware with whatever they wanted, so users like me can opt out of the cloud driven solution.
The nice thing about a hack like this is you, the creator, have full control over exactly what is exposed or how. There's no cloud, no external control, no unwanted firmware updates, nothing. If everybody was willing and capable to engage with their hardware at this sort of a level, there wouldn't be this crisis of insanely insecure hardware being sold to uncaring consumers, imo!
One thing I've learned when dealing with cheap PoE CTV cameras, is that there really are only a very few IoT chipsets for various things, everyone seems to be using the same ones (except for a subset of boutique ones reusing off-the-shelf more complicated ARM processors or Raspberry Pis or whatever).
I'd love to see that more standardized and things like OpenWRT for all sorts of IoT junk, giving back control. Opinionated things like Valetudo https://valetudo.cloud
Y'know what I'd love? For all IoT crap to feature a socketed ESP32 or whatever. The vendor can ship whatever garbage software they want to it, but maybe in the future when Wifi 2.4ghz does eventually die as an example, we could all just swap the controller chip with one that supports 5ghz wifi. This will never happen since the world prefers us to throw all that crap out to buy new crap, but it's nice to imagine!
This is impractical for a couple of reasons:
1) Socketed chips add significant cost in a number of ways as compared to CoB or just standard soldered chips
2) This would likely violate most FCC/CE/C-tick/etc. certifications.
3) The whole assembly would need to be designed to be field servicable so you could access the circuit boards, which would also add cost (and possible warranty issues).
In the end, building a product that could properly facilitate this would just wind up costing more than viewing them as disposable units that you toss out when a newer version of something is available. This is optimal from a capitalism standpoint, but suboptimal from a sustainability standpoint.
> 1) Socketed chips add significant cost in a number of ways as compared to CoB or just standard soldered chips
Yep, that's probably true.
> 2) This would likely violate most FCC/CE/C-tick/etc. certifications.
IANAL but that doesn't seem like it can possibly be necessarily true, since most computers let you replace the motherboard and wifi card.
> 3) The whole assembly would need to be designed to be field servicable so you could access the circuit boards, which would also add cost (and possible warranty issues).
Not all, but most IoT boxes I've seen already are easy enough to take apart, it's just that there's not much to do with it once it is apart. So I don't think this would be a change.
I'm not saying any of it is impossible, just that it is costly (based on my direct experience at a number of hardware companies).
For an "IoT box" type of product there would likely be fewer issues with the certifications and swapability.
For IoT devices like light switches, bulbs, smart outlets, or anything else where the 120V/240V power is exposed vs. isolated by a power supply (as in the case of a PC or "IoT box") it would likely be too costly to do in a conformant way. Particularly when the tinkerer consumer base that would actually value this is maybe 5% of the total market.
Better yet, just require it to publish full source code after some embargo period, maybe 8 years. Managed by an independent accounting firm. Also require a standard programming port.
This would be okay for iot bricks but more useful for laptops. Company gets X years of secrecy and when they abandon support, they open up the secure enclave and let FOSS devs go to town.
Any recommendations for ONVIF-compliant cameras for home use?
I've tried a handful of used hikvision / dahua in the ~100usd range but they don't play nice with anything other than the vendor's software. Like VLC / open source VMSs can't play the RTSP stream. And even then, its a crapshoot whether features like stream configuartion or PTZ work.
I know the ONVIF group publishes a list of verified-compliant models but it's been a pain trying to find one that's affordable and in stock.
I've heard from devs that work on this stuff that most of this pain stems from how loose the ONVIF spec is. Too many optional features (even per "profile"), too vague on requirements, leading to lots of vendor-specific metadata / camera quirks.
I went through a bit of a spat with cameras, and had luck with things from Amcrest, Reolink, and various similar ones on Amazon. All worked with VLC over RTSP, though I didn't go deep into PTZ setups.
It's even more of a crapshoot because some of the cameras were absolute shite until I found some sketchy Chinese firmware of a particular version, which made them suddenly beautiful.
All of these are very securely cordoned off and unable to contact the Internet at large, of course.
Is Zoneminder your main interface? I've been using it for several years with a few Reolink 5MP cameras, and maybe it comes down to choices I've made which I should revisit, but it's painfully slow (say, 30 seconds) to start playing, or seek within, an event video. I record only events.
I am now experimenting with the RLN36 NVR instead, and thinking about having enough disks to record continuously instead of events only.
Ideally I want continuous recording, and I want a timeline of events that aren't separate files, but are just shortcuts to alarm times within the continuous recording, with minimal seek delay. Interface must be friendly to small screens (phone size) which the RLN36 web UI isn't particularly. Maybe the zmNinja app.
I used zone minder for a bit until I realized I don't actually care about recording at all for my use cases, now I just directly VLC to the camera itself.
If I were to set it up again, I'd go further down the home assistant path (one camera I got setup so it appears in HomeKit, but I never bothered getting the rest).
My comment is maybe too-indirectly implying that these skills end up getting applied in careers where surveillance is added on top of these sorts of connected processes. The hobby can be as benign as we like, but paychecks change what people are willing to tolerate...
I have a hard time connecting the dots in your argument? For starters, there are already desks out there on the market with this functionality build in. As an example, my desk can be controlled through Bluetooth.
It's why I also have trouble seeing the link you seem to find obvious, the global dystopian surveillance and data-brokering aspect. Specifically in relation to personal hobby projects like this, as the author is doing nothing new and there is absolutely no link to data-brokering...
The line connecting the dots is that some who practice these skills end up adding those surveillance features to products in their careers. Not a hard leap to make, unsure why it wasn't obvious.
Some people who study computer science end up using those skills to write those products with the surveillance features. Should we not practise computer science as well, just to be on the safe side? I don't understand this argument at all.
> Not a hard leap to make, unsure why it wasn't obvious.
Don't be dismissive. Just because others can't see it, doesn't mean we should be dismissive of __them__. I know it is subtle, but I think this is important, especially if we want to be taken seriously. The whole problem is about how small things add up, and often how we can't even see the issues with the small things themselves. People's views are going to be skewed by their experiences and often, with regards to this topic, how effective (or seemingly effective) their governments are. The line is thin and hard to see. That's the whole problem in the first place. So don't chastise people who can't see the spiderweb just because you were at the right angle to see it glistening in the sun.
> I have a hard time connecting the dots in your argument?
Unfortunately, the root of the issue is that the line is very thin and hard to see. Which is why it gets crossed so often and only realized post hoc.
I apologize for the lengthiness that is to follow.
For a desk, it's something that seems nowhere near nefarious, even if it leaks to the internet, right? Well we could imagine a world where your boss can see this data because they set up such a system inside the office. Probably with some good intent too like raising all the desks at night to help janitors clean under them or something like that. But a new manager comes in and uses that data as a means of determining how much you are working. Might even implement policies like having to stand up and sit down every so often because they are reading blog posts on worker productivity and sitting too long. It can be "in the best interest" but can quickly become abusive. The concept of "turnkey tyranny" isn't limited to governments and it's important to remember tyrants don't view themselves as evil. More often they just view themselves as "better", "know what's best", or "ends justify the means." Generally it is an extreme version of Main Character Syndrome (which MCS is not too uncommon in our communities...)
As a clearer example, where we have the advantage of hindsight, I think social media can fit in here. I very much don't think social media started with bad intentions and honestly, I don't think people today working on it have bad intentions. It's more the problem with "the road to Hell is paved with good intentions." Social media does good, it brings people together across the world, and allows us to have competing (in a healthy way or unhealthy) views. We're doing it this very instant! But one issue at the core of the problem is "engagement." We know these algorithms optimize for is, but what's it mean? We can see how it is based on activity. Things like post interactions, shares, commenting, likes, and so on. But think about this problem hard. How do you __actually__ measure engagement? How do you __actually__ differentiate "good" engagement from "bad" engagement? Can you find natural language words for this? I bet you're going to have a really hard time. And then an even harder time expressing this in code. So what happened? Well we got an overly simplified version (obviously, given that this concept is essentially intractable and highly dynamic), and got metric hacked.
These people are trying to do the right things, but just have a limited scope. It's worse if they don't realize their scope is limited (see MCS). People who don't understand the metrics just understand that they are metrics and so optimize for them. Managers can dismiss engineer complaints because these people can't speak the same language and are working at different levels of abstractions. It's a whole complicated mess where the main issues come down to the chaotic interaction. It is almost never someone seeking out to perform evil, but people who can't see beyond themselves (which is hard!). And even when we can see beyond ourselves it is hard to see very far. Be that into the future, into other "tribes", or whatever. The best defense we have against these things is to stay defensive, communicate, acknowledge concerns (even if moving forward. Just means tread carefully), and to balance short term rewards and long term (short term is easy to measure, but can easily lead you away from huge future payouts). We live in such a complex world that to maximize your objectives you often need to maximize other peoples objectives in certain situations[0], because if we treat everything as "zero-sum", "single round", or similar naive approximations, we will push ourselves away from our goals. This is the tyranny of complexity, how trying to do what's best is always far harder than it seems. And worst of all, it's incredibly hard to measure the impact of your decisions through these chains of interaction.
So if all this was hard to understand, I get it, because that's also the problem. It's the little things adding up, not any one or even a few big thing/s.
looking forwards to the black mirror episode where the user's standing desk height is used to reverse engineer all sorts of tidbits about the users habits to sell them more stuff
It looks like it could come in handy for many esp32 projects.
p.s. In case the author comes across this comment - Absolutely superb write-up, your writing style reveals your curious and positive attitude, it's totally inspiring! I wish I could easily subscribe to future publications, like the emails I get from Ken Shirriff of https://righto.com. Also, your C++ is clear and easy to read, good job. Cheers.
Edit: @Klathmon, thanks for the info, that was very fast :)
if you search for "prototype board for esp32" or "breadboard for esp32" you can find the same board the author used. You can also find ones with strips for each esp32 pin, instead of just a via and pad. And you can find solderless versions where the connections push in vertically (typically white with five holes connected perpendicular to the "valley" that a DIP chip would insert). And you can find "breakout boards" with sockets for the esp32 and pin headers and screw terminals for each pin.
The latter! At some point I got bored of having to retrieve it every time I had a DIY job to do, so I bought a really cheap one and left it in my home office
Is that actually an ethernet port, or is it just an RJ45 for something like I2C, UART or some other protocol? It's also got a little port for a Bluetooth controller, which came with my desk. I bet it's possible to reverse engineer whatever protocol that is using over bluetooth/BLE.
I have this and it works great. I wrote a script for it that checks my google calendar to make sure I'm not in a meeting (nothing worse than your desk suddenly moving positions when you're in the middle of talking to folks) and then moves my desk to a standing position for a configured amount of time every day. https://github.com/signalnine/upsy-desky-autostand
Gostand does as well. Hmm. Would they have bothered encrypting data going across that wire? Seems unlikely. Would using actual ethernet have been cheaper than DIY? Really might be. Interesting thought, I do want to toggle the desk height from emacs and probably from cron
In practice, it is similar to how a firearm allows one to shoot at themselves in the foot.
Electrically it seems like a low speed bus should be the ultimate in reliability. Sadly, I2C peripherals are implemented with high speed digital logic and sometimes no filtering (or present but not enabled)! They might react on nanosecond glitches of the I2C clock line or very high frequency noise that is hard to see.
It boggles my mind that I2C is implemented so horribly but continues to be used… for decades.
I have no experience with I2C whatsoever, but it sounds like the HTTP/HTML of the electronics world: Full of quirks and design failures, but it's what everyone knows and understands, so it won't ever die...
(This post emphatically not endorsed by my employer.)
[1] https://github.com/gcormier/megadesk
[2] https://github.com/gcormier/megadesk_companion