Five years ago, I wrote a series on getting started with your own MQTT-based home information/automation network. Five years is a long while in Hackaday time. Back then, the ESP8266 was a lot newer, and the 8266 Arduino port wasn’t fully in shape yet, and the easiest software framework to get MQTT up and running was NodeMCU; so that’s what I used for the article series, and as a consequence a handful of devices around my house run minor modifications of that basic “hello world”, but doing useful stuff.
Since then, NodeMCU has changed a bunch of its libraries and the ESP32 has replaced the ESP8266 in my parts drawer. If you tried to run my code, you’d find that it won’t run on an ESP8266 without porting or compiling an old version of NodeMCU for yourself anyway, and it won’t run on an ESP32 at all. When [Chris Lott] tried to follow my guide, he discovered that Micropython is probably a better language choice in 2021. To minimize lines of code, I’d agree, although the Arduino and Espressif’s own native IDF have grown into the job just about as well. In short, anything but NodeMCU.
But my home automation system doesn’t care. Those little guys are running 24/7, flipping bits like it was still 2016. Thermometers, light sensors, and power meters haven’t changed much in five years, and although I’ve revamped the databasing, display, and user control a number of times since then, using a fixed communication transport protocol means that they’re still talking the same language. Indeed, even if NodeMCU is dead to me, the MQTT content of my original series is all still valid, and installing a broker on a Raspberry Pi has only become easier in the intervening five years.
So I’ve got a bunch of legacy code running within the walls of my own home, and it makes me nervous. If the devices fail, or maybe when they eventually fail, it’s not going to be “just flash another ESP8266 and replace it”, because even though I have some ancient NodeMCU binaries sitting around, I know when to throw in the towel. But there’s no good reason to pull them down and start reflashing either. Except that it makes me a little bit itchy, just knowing that there’s orphaned, dead-end code running all around me. Surrounding me. Staring deep into my hacker’s heart.
I know better than to tear down a running system, even though I could do it one device at a time, and each module would surely be a simple, independent fix; even though I’d love the excuse to play around with Micropython and its MQTT implementation on the ESP8266, or maybe even swap some of them out for ESP32s; even though these were all temporary quick hacks that have somehow served for five (5!) years. I certainly know better, right? (Right?)
Go on, rip em out and replace them! It will provide at least 5 articles, so it’s a business expenses, right?
Hand me down hardware. Best thing ever.
FULLY agree!!!! Come on, Elliot … do what all self-respecting hackers do and spend 2X on the project so you can re-implement it in all new hardware and software, just to accomplish the same thing that it’s already doing! But THEN your heart will be teflon coated against the angry stares of those aging 8266’s and that heartless NodeMCU code running on them! And if that’s not enough … well, just do it because we all know that you want to!
:)
Your Hackaday fans anxiously await your 5 new articles!
Feel free to do more, we’ll wait!
What really kills me here: There is a 433MHz transmitter on the ESP. A device that already has wifi. I don’t know how large your property is. I don’t know if wifi cannot penetrate your walls.
But that always leaves me with an open mouth. Wouldn’t the first step of a home automation enthusiast be rolling out 4 cheap wifi APs?
I simply don’t get it…
Hi! A mix of all of the above.
We can buy 433 MHz switches in three-packs for €10, and you get a free remote. (I’m swimming in the remotes.) Because of this, we have like 15, 3 of which are outdoor/weatherproof. Nearly every German household has three or six or nine kicking around — we got given most of them from my mother in law. So rather than WeMo switches at $45 each or whatever, I used what we have.
But also: WiFi doesn’t penetrate our floors. We have the main router in the office in the attic, and two floors down, we can’t get signal. So we have a repeater on the ground floor. And you can’t get that signal in the workshop/basement. So we have a third repeater in the basement hallway. Because of this “complicated” network topology, and a crappy router on top, they all need rebooting once every couple days.
The simple 433 MHz transmitter (with shown dipole antenna out of two wires) reaches through all of this. And it cost $1 on eBay. And it works 100% of the time, regardless of whether the router needs rebooting. The real limit is that the signal is unidirectional, which is lame b/c you can’t know if the switch is on or off.
For low-bitrate signals like the power switches, 433 (315 in the US) is ideal. I’ve also got a similar nRF24 gateway that I’ve played around with, but the range is limited to one floor, or even room. Still, it’s fun to play with.
There’s nothing wrong with diversity. :)
I see now, if it really is that powerful it could help me send smart-meter data out of a basement room with a heavy fireproof steel door. My real problem is paranoia: I live next to an airport and even though ISM and 433MHz is legal here as well, I don’t want someone knocking down my door because the Chinese components are not perfectly free of harmonics on other frequencies.
I would reach out to hams if I had time or knew any around here and have them scan it.
Is it allowed anyways to continuously transmit on 433MHz? Also I’d be leaking lots of private data, should encrypt my power usage before sending it. Too many unknowns.
Wifi, that comfy blanket with built in WPA2 and the assurance it is perfectly legal. I love you ESP8266 and 32.
I dunno about continuously trasnmitting. These things send out short bursts (half a second?) a few times just to make sure that the command is heard, but then that only when you’re turning it on or off.
I _was_ extra paranoid when we had lights on our Christmas tree, for instance, and sent the off command every hour from midnight to 7:00, just to be really sure. I don’t think that was necessary.
And you hit the major issue of home automation: all the fancy gadgets you have are quickly becoming obsolete, parts become unobtainium and compatibility issues crop up.
Or as it happens, parts start to fail and while the system is down and you try to plan how to fix it, you actually find that you don’t need to know the humidity in your closet, or the temperature of your living room, and you start to question why you built it in the first place.
A home that depends on automation is short-lived and expensive/tedious to maintain. A home that works without doesn’t need any.
“A home that depends on automation is short-lived and expensive/tedious to maintain. A home that works without doesn’t need any.”
A society that depends upon technology is short-lived and expensive/tedious to maintain. A society that works without doesn’t need any. Yea Ha! Bring on the Amish.
Lol, But a society built on it is cheap to maintain – its the same cost but distributed over a huge population, all with the same vested interest in the technolgy base surviving.
The entire reason why we have to do so much work is to keep up whatever we have built so far, because we’ve made it to sustain ever-expanding populations of people and can’t back out of it. We have this idea of hunter-gatherers as being always on the brink of starvation and death, but they were the original affluent society. They had all their material needs covered. But I digress.
A house is built to last 50 years minimum, 100 years if it’s a well-made house, and many centuries if the architects were smart about it. However, that means none of the basic functions of the house can depend on active automation. It has to stand the test of time pretty much by being heated, cleaned, occasionally painted or plastered, and basically just by being lived in. This sort of robustness requires that everything is simple – gravity air exchange, materials that breathe and dry out on their own, forced air heating or simple radiators, at best a simple fan on a timer in the attic for ventilation etc. If the house is built in a way that demands active sensors and feedback loops to stay comfortable and healthy, then it’s going to break down sooner or later and develop moisture damage, mold, etc. and you have to tear it down. In other words, the home itself is passive.
All the automation we’re talking about are gadgets and trivialities that you can easily live without. This stuff is designed with the foresight of a five-year-old child. It’s not even meant to last. Your smart light bulbs stop working a few years later when the company that made them shuts down the servers in favor of an upgraded product. Anything you wire permanently “into the walls” will have to be replaced in a decade because it either stops working, or becomes obsolete otherwise, so wiring them in was like building a home theater mancave and making all the equipment Betamax instead of VHS, or HD-DVD, Bluray…. a couple years later you will want to kick yourself anyhow as you tear it down and replace it.
Or, if you’re studied systemantics:
>”The Fundamental Failure-Mode Theorem (F.F.T.): complex systems usually operate in a failure mode.”
Point being, complex systems usually fail to work the way they’re meant to work, but people rationalize it as proper function because they don’t understand what’s happening.
In terms of home automation, you can for example have the ventilation system stuck on low, and people may complain a little about stuffy air or high temperatures, but since they’re told how smart and rational the system is, they simply conclude that it’s working as normal: it’s probably just saving energy by not turning the AC on. Then people start to notice spots of mold rising up the walls, someone calls the building management, and suddenly you’re ripping out insulation and rebuilding walls.
I think this is a business problem more than a complexity problem. There are some types of automation, like door sensors, that I wish were everywhere.
And there’s no technical reason that kind of hardware can’t last 50 years or more. Even the batteries should be good for 25 with LTO rechargable.
Well, if it was necessary for houses to have complex automation – like a life support systems on Mars – then surely we would have this thing down to the dot. As it is not necessary, it cheaper and better to design houses without automation, and then add whatever gadgets on top.
And that makes is a business problem, because we’re fundamentally dealing with a market of vanities and luxuries that serve more the curious hacker and technophile, rather than anything most people -really- need. At the end of the day, it doesn’t matter whether I can change the hue of my light bulbs from my smartphone – eventually I would just leave them at one setting, uninstall the app from my phone, and forget that it even exists.
Given that these things are made essentially for toys, there is no technical, practical, OR business reason why they would need to last the life of the house.
Techno Amish it.
But this is a custom system, and the parts can be swapped out easily enough as long as the protocol matches, so it’s basically fine.
NodeMCU?
You mean the Lua, not the boards?
Have you seen https://github.com/whitecatboard/Lua-RTOS-ESP32/ which feels much more like a Lua-OS than NodeMCU-Lua?
Looong ago I looked at NodeMCU-Lua but I got tired of building application specific versions of it. Due tu the tight ESP8266s, you just couldn’t have a firmware that would fit all situations. So then one starts ask: “Why not use the SDK directly instead of 1st building a custom Lua firmware to then write the application upon?”
Ok… it has been a while… maybe NodeMCU-Lua has improved a lot since then. I should revisit it. My to do list already is an anacoda! _SIGH!_
No, hadn’t seen LuaRTOS. I’m not really a Lua expert, though I really like the simplicity/interactivity of the language and the way it plays well with C. I’ll go check it out.
This hits close to home,, my x10 network and web interface I coded up in the 90’s still works… there are so many options now but ,, it still works. There are zero things I would preserve in a greenfield build, but my motivation to change it is limited. I probably won’t rebuild until it dies, or I ‘need’ something it can not do.
Yah, lets do everything in x10, interfaced with RS232, programed with COBOL and running on a hmmm 8051 and they’ll still know how to fix it in the year 2500.
That’s too hard Just have kids, and have them go around turning the lights on and off
Today’s kids grab their holy slave labour spy phone product and cry into the app to magically toggle the switch…
Ever hear of ‘heyu’? .. x10 replaced kids
I have a toolbox which contains a number of tools my dad gave me. Some of them are even tools that his father gave to him. I am sure that advances in the art of metallurgy mean today’a hammers, pliers, and screwdrivers are far superior to the ones in that box, but as long as they perform their intended task, there is absolutely no reason for me to worry about replacing them.
Electronic devices, like anything else we create to ease or improve our lives, are tools. Nothing more. The fact that some of the electronic devices I use might contain an obsolete processor or “run COBOL” is of no concern to me. Until they fail to do what I need them to do (either because of an innate failure or because a change in external protocols/interfaces has rendered them functionally obsolete) there is no reason to replace them, either.
The one possible exception I would recognize is if said device was associated with “mission critical” functions.. my furnace, my well pump, or my electric service. I still wouldn’t care if it contained legacy hardware/software, so long as I had sufficient spares to assure uninterrupted service while I buy the next generation replacement (which will then spend the bulk of its working life in a state of obsolescence, too!)
Like it, I too have a great many tools from both grandfathers (gave away a great many more from the one who spent much of his life being a mine engineer – I have no need of 3″ and greater imperial wrenches, but the locally based steam ship did) and also have no intention to replace them, infact a few of them I’ve refurbished to be better than a modern equivalent, as its actually made of quality steel not Chinesium.
But its a little different with electronics you also have to ask if this old stuff is opening up security holes on your network, consuming more electricity than a modern equivalent by enough to be worth changing/upgrading it. Also if its a system you built yourself you have to ask do you want to keep using the legacy code you created and used in a language you don’t really use anymore – can be easier to maintain and fix the upgraded version, as you will create the software with your current language of choice. A system you didn’t build yourself you have to ask is it still supported, and does that matter. How ‘mission critical’ it is is also a good criteria.
Same here .. X10, along with MQTT .. have spares of ‘most’ X10 devices.. All someone has to do is unplug everything and the house is back to manual..
As it happens, X10 is still available: x10.com
What gets me, is how lazy people have gotten.
Alexa turn on (station). Alexa, lock the door.
Whatever happened with tuning a radio yourself or getting up
and locking the door yourself? First off, I wouldn’t trust
any lock that needed batteries or one that’s hooked up to a
network that possibly could be compromised.
You hear all these stories about people listening in on baby
monitors, looking through security cameras etc.
Then you have all the tv and radio stations saying over and
over and over “to get the latest news, install the (station)
news app. If I installed every app I’ve heard about over the
last month, my phone would probably crash. Why would I want
an app? Don’t I pay enough for cable? Not to mention the fact
that I can turn on the radio to my local all-news station?
Between robocalls, spam, and incessently hearing about (station)
apps, I’m awash in pure utter nonsense. People have become
dumber because of the hours wasted in a day on this crap.
Don’t get me started on the medicare enrollment commercials.
I would love to have a device that would mute the TV every time
a commercial I’ve seen probably thousands of times comes on.
I can turn my lights on/off myself thankyouverymuch.
The technology is wonderful, don’t get me wrong.
It can help people who are unable to do everyday things.
We waste more time listening to commercials, dealing with
spam, robocalls, and every other little thing clamoring for
our attention. I foud the perfect cure however.
I shut everything off, and go for a nice walk in the sun.
Without that disconnect, I’d probably (make that definitely) go sane.
The last thing I need is to come home and have the house needing
the latest patch/upgrade. Where is the line drawn? When is enough enough?
My personal line is anything than I have to maintain. Amazon spying in my bedroom doesn’t really bother me, I’ll just turn it off should I ever decide to host a revolutionary meeting there. But DIY project type home automation is absolutely unnacceptable to me
Same reason I won’t touch Arch Linux. I want tech to be independent and keep track of itself. I don’t even like to build or program any tech at all unless it’s important enough to do it the right way, following all industry standards, with PCB designs and a 3D printed case and full documentation.
Few words make me lose internet in a project faster than “perf board”. Bringing the hardest part of work, the precision manual assembly, soldering, and tweaking, home to do it some more on the weekends is not something I want to do.
????
Are you sure you posted on the right website?
But that just means they will know when you are hosting your meeting, and with enough data who else is in attendance too!
To actually be ‘safe’ you’d have to randomly turn the thing on and off for random lengths of time while not planning to blow up you local government/amazon depot or cheating on your partner etc… Which rather negates the point of having the device in the first place, if you can’t actually use it without selling your soul… (as even when you unplug it is data on you, and rather informative over time forming a solid pattern).
I can understand not wanting to do more of what you do at work at home.. But I don’t understand your dislike of Perf board, the stuff is magic for reducing the work you have to do for that odd one off project, PCB production/ design and outsourcing takes more money and time!
I’d probably like perf board more if there were more modern tools to work with it. Without software, you’re basically all on your own as far as creating a somewhere clean layout that isn’t super mechanically delicate. Trying to figure that out takes more time than doing the layout.
And they’re much larger, which makes case design harder, especially when you don’t have surface mount, and the whole bottom needs several mm of clearance for solder, plus, without CAD models beforehand, you’ll probably wind up having to measure and design a print just for that unit, rather than having a real repeatable design.
Perf is great for one offs, but if time and money are really a concern, there’s usually an off-the-shelf version. I’d rather do a PCB and make someone commercial quality and future proof.
If I was planning to blow something up, I could always just stop using things a week ahead of any meetings or activities. But in practice, most of us don’t have major things to hide(Aside from those doing more… interesting things in the bedroom who prefer that Google employees don’t get a free porn show).
And unfortunately, there are so incredibly many problems that it’s very hard to protest all of them. Especially when quitting one, like Google assistant, might increase others, like the amount of waste you make by burning the spaghetti.
Especially when you ride the bus, a few minutes delay can mean being an hour late, so convenience is almost always worth it.
Although I would love to replace the few proprietary bits I have with open software. I’m very slowly working on a P2P database solution that I’d like to someday expand to cover notetaking, calendar, and Bluetooth tile tracker management.
I wouldn’t call myself a master of perf board, but I find it pretty trivial to put the generic circuit layout onto it without serious planning every time I’ve used it so far… A few times I’ve noticed after the fact I could have done a more elegant layout, but its a working circuit put together quickly that does the job.. When you don’t need the tiny surface mount, etc you have no choice but to to PCB.. (And personally for now I’m still avoiding surface mount as much as possible – hand soldering with only an iron and a rather cheap one at that (though I hope to get the PID controlled hot box capable of doing reflow built at some point soon) means anything remotely complex can take rather alot of concentration to populate, those pesky surface mount components are just not fun to work with by hand.
If you have it on constantly then you’re giving Amazon and whoever vast amounts of information about your life, and probably the ability to infer more by combining data from that and other other things. I would prefer not to.
I really wish we could have a proper, fully standardized, off the shelf, open home automation. None of this reflashing by carefully taking devices apart business. Give us a USB-C or micro to reflash, with full Arduino compatibility, and add an Adafruit STEMMA connector to every device.
Never mind the extra few bucks to make an isolated power supply. Just make sure these devices are something we can confidently use for the next 30 years, or at least the next 5. I don’t want a bunch of customized hand built stuff at home that I have to maintain. But unfortunately, none of the existing stuff is anywhere near 100% reliable, and it’s all cloud based.
And we seriously need to move away from WiFi based devices. Enthusiasts don’t trust random junk from HK on their network, and average consumers aren’t going to demand full local control, so it can’t really ever be a dime a dozen mass produced standard the just works.
It’s enough to make someone wish X10 were just a little better, so we could stay with that forever!
X10 was /is? an awesome concept. With modern wiring, it just works. I really miss it! Using the powerline for comms when a device is inherently required to be connected to the mains is a no brainer. Using wifi instead introduces another potential failure mode. Frankly, the likes of Samsung smartthings today are inferior to the X10 net I had 20 years ago.
I also struggle to understand the love for Mqtt. Why use s protocol that is not only point to point, but also introduces a single point of failure? If tcp/ip is your poison, wouldn’t multicast be a better fit? The lamp can listen for changes in wall switch state – all fault tolerant, potentially.
>With modern wiring, it just works.
Well, assuming everything in your house is wired up to the same phase. Where three-phase power is used, it’s common to have lights, sockets, stove, etc. on different phases to spread the load out more evenly.
Towards the end MQTT started heavily using wireless. At most, you’d just need some extra bridges, if your stuff didn’t have native wireless support.
I had an X10 home automation system for 10 years and abandoned it when I moved three years ago. Two years ago I started a new system based on open-source software and MQTT, and it is 10 times faster, 10 times more reliable, and much more fun and satisfying to use.
MQTT is wonderful because it’s a reliable standard. I actually spent about a month working on my own solution that used multicasting and built in encryption, but abandoned it because…. MQTT is the standard.
I wouldn’t call it a great standard, it doesn’t support unreliable messages because it’s TCP, SSL encryption is inconvenient because of domain names(Or was, before I started using my custom HardlineP2P tunneling app!).
But it’s a standard.
Really, I think there should be an open, unencrypted standard for multicasting to smart bulbs and the like, with all the reliable retry built in. But creating new standards rarely seems to happen, and manufacturers all want their cloud and account based crap.
There is an extension to MQTT, MQTT-SN, that could be used to multicast to smart bulbs (and other devices). Among other things, it defines a QoS level -1 that can be used to send a PUBLISH message with a “short topic” name (always 2 bytes length), or predefined “topic ID”(also 2 bytes), without the need to establish a connection. Although the MQTT-SN spec says such messages should go to a gateway at a predetermined address, the address could be a multicast (or broadcast) address.
Unfortunately, the MQTT-SN spec does not define any lists of predefined short topics or topic IDs, so those would need to be standardized.
The MQTT-SN spec is at: https://www.oasis-open.org/committees/document.php?document_id=66091&wg_abbrev=mqtt
Does anyone actually use SN? I looked into it, had to make a complicated bridge to translate between SN and regular MQTT, and gave up.
Elliot Williams said:
“translate between SN and regular MQTT, and gave up.”
My thought is thought is MQTT-SN could be used by itself, in particular, the QoS -1 PUBLISH and use a multicast/broadcast destination address. That would bypass the complexity of “full” MQTT and still be based on an open standard.
Ever tried home assistant? Does many of what you want…
You should check out KNX. It’s a bus based protocol standard, is open, and fully standardized, and is well matured. It’s not common in the USA, but it’s used in large deployments in europe and other countries including mine, and can also apply to homes. Several companies around europe make devices that all work together with each other. I also managed to find parts for KNX transcievers on digikey and even an ardunio shield, so you can make your own.
Unfortunately the off the shelf parts are crazy expensive. The other issue is that the KNX network is unencrypted.. but it’s all done in a cable-based bus network anyway and you’d need physical access to tap into it, so it’s no big deal.
To get a reliable MQTT device using an ESP8266, just install Tasmota. It’s as reliable as a stone axe. https://github.com/arendst/Tasmota
i have a network of 4 temperature sensors around my house, since Apr 2008. they started out with 8-pin PIC12s converting the analog signal from an LM35 to a 3-wire serial protocol. i found out about the DS18B20, which speaks a nice 1-wire protocol, so when one failed (from abuse, i think — kids) after 7 years, i replaced it with the dallas device even though i still have a pile of PIC12s and LM35s. ran a hybrid network for a couple years until the outside one failed (weather exposure is rough!), and then i replaced all of them at once with the 1-wire ones.
to implement the 1-wire protocol, i changed the “hub” from a PIC16 on the parallel port to an STM32, accessed over the USB debug interface. it uses gdbserver, and i set some bytes in the memory to tell it what to do, then send a “continue” command, and a couple seconds later interrupt it and look for response bytes. :)
one day i found out the android phone i’ve been using as an alarmclock has a barometer built in, so i wrote a dumb little app for that to let me poll the barometer over TCP/IP.
i’ve since abandoned the control portions but it used to control the furnace through a relay board i’d made with a PIC12 and put on the old 3-wire network, and it controlled some window fans through X10.
so all along the daemon has had a configuration where the addresses are like “i2c:3f.1” (3-wire) and “x10:b1” and now “ow:28aad05207000076” (one-wire) and “tcp:192.168.1.123:3000” (the barometer).
and it has been recording the temperature every 30 seconds for 12 years…started out as a classic LAMP project but i noticed mysql is unfathomably slow at bulk data transfer. and i didn’t really mind that it didn’t have a very optimal representation of the data but once the database crossed the 1GB mark, it became more and more squirrelly to run the recovery process after a forced reboot. so a couple years ago i replaced the database parts with a bit of C code. the whole record now takes 104MB and can be read in only 17 seconds.
and the CGI UI was rendering the data with gnuplot. honestly, i don’t remember what upset me about gnuplot, but one day i sat down and wrote my own C code to render a plot, and i’ve been real happy with that. it’s fast and does a good job, especially now that there’s the barometer data which needs to be on a different axis entirely.
my point here is, i’m just like the OP but i don’t have any illusions about maintainability…of course as stuff breaks or as my needs change, i’ll redesign parts of it. that’s how it’s been all along. it’s always been a modular mishmash of different technologies being substituted out one at a time. if i die before my wife, like everything else i do, it’ll work on its own inertia for a while and then it’ll just be another thing to shovel into a dumpster.
>it has been recording the temperature every 30 seconds for 12 years
And what have you done with the information?
If you record something for 12 years, that isn’t ‘information’. It’s ‘data’. It only becomes information when you reduce it to the useful parts.
I rephrase the question: what information was obtained from the data?
i have a web interface that allows me to view it at will. i use the outside sensor’s history like a historical weather reference. sunny days can be tallied from the sensor in the greenhouse. once i went through and figured out what i set the furnace thermostat to every winter. you know, pointless questions
Fair enough.
I set the thermostat to whatever makes my house warm, seeing that winters vary a lot. Judging by the data from a local weather station, there doesn’t seem to be any discernible pattern or trend in temperatures for the past 20 years, except for a slight upwards tick which can be attributed to global warming.
I once thought I was seeing a 5 year cycle of cold and warm winters, but it I was wrong.
Ah, the joy of seeing the maker movement find the challenges that industrial automation integrators encounter. The usual options boil down to “cut over” or “staged”. Since the backend is the same (MQTT), you got lucky and can do the staged with minimal effort!
I would like to see some articles or case studies from the real world of hardware upgrades in industrial production settings. Any that I would write would be underground mining vehicle focused.
I wander how usefull would retro computing be to create long lasting code. For example RPi with RISC OS and it’s Basic instead of Linux and C/Python or programming ESP32 built in Basic instead C.
C dates back to 1972 (near as makes no odds) whilst RISC OS came to us in 1987 – so how is RISC OS “retro” compared to C?
C has proven to be far longer lasting than anything else and still underpins all the good stuff: you use it to build your Python environment in the first place.
Well, for the sake of long-lasting scripted code, hopefully you use C to build your Lua environment, because Lua is so much easier to build and the sources for it are small enough to just keep alongside your application-specific code and be statically linked, which gets rid of any problems versioning the scripting language.
I know whenever I’ve wanted to code anything I’ve not validated and/or developed in C… the stars didn’t align in my favor… or stations or something like that excursionary diversionary inquiry desperately handled me away from doing so.
And then the kids come along and say “hey, here’s Rust. it will cure all your ills.” But then they write their own compiler and linker rather than writing a front end for gcc, thus proving they have no idea what they’re doing.
If it relies on make, it needs to be rewritten anyway. I hate make.
Rust being so not C in some core underling mechanics would probably be harder to shove through gcc than something built from the ground up with those assumptions in mind..
So personally I don’t see that as a big deal.
The Rust compiler is LLVM based, instead of gcc based. So no, they didn’t make a completely new compiler. The Rust specific parts of the compiler are written in Rust.
That’s not such a nonsensical idea. Older computer languages generally emerged from a single source and had the benefit of competent computer scientists, mathematicians and research institutions spend much time working on them, leading to extremely mature solutions. Take FORTRAN for example.
Compare that with modern open-source software where everyone and their dog can contribute. Now that’s a great and admirable thing but surely a potential downside is that ad-hoc “features” get added (or deprecated) at such a relatively fast rate that it may be hard to keep up with and before you know it, which version of some language spec or library you are using becomes a critical factor.
Ah, one of the flaws many do when DIY’ing.
If/when you do a project like HA, you need to build spares!
Based on the happy wife/happy life principal, if you get the spouse hooked on it and it breaks and you go “Well dear it’ll be a few weeks while aI develop a new system” You’re the one in the hot water and may never be allowed a DIY project for import stuff again.
I did X10 years ago when I was in an apartment — had spare parts for most of the modules (one or two I didn’t but they were none critical fluff just for me)
I’m still on probation for having the kitchen apart for 4 weeks, 5 years ago. I cannot seem to explain that “a couple of days” was what was required for 2 shelves and an extra flap of counter, not the fully scope crept version of 3 new cabinets, 4 shelves, new recyclables handling area, new countertops, replacement sink, new plumbing and faucet. Not to mention the 8+ trips out to stores because almost none of the stuff I had on hand I was gonna do the quick and easy version with was “suitable”.
It’s why I’m glad I’m single!
Don’t have to apply that principal to my projects!
Ah yes, I see your mistake. Thinking that any particular piece of code would serve you beyond five motherfucking minutes. See, this is the issue: It’s not so much that you can’t piss against the wind, but rather that abandoning any piece of software for more than five fucking seconds MAKES IT IMMEDIATELY OBSOLETE, so you’re perpetually condemned to tend to all your gadgets or immediately lose all their functionality. Wise users be warned – unless you want to spend your life updating the firmware of your wifi-aware washing machines, STOP GIVING IN TO THE POINTLESS IOT TREND. You can thank me later…
Why of course it’s connected. How else is it going to watch it’s soaps?
Do it, you know your OCD will destroy you if you don’t. I love the art work for this article, but my OCD is too strong for me to not say this. Excalibur is not the sword in the stone, the sword in the stone was a worthless piece of metal, it was a test.
ALL of this! THIS is why I hate ARM, and will soon also hate RISC-V. Not because I don’t like their architectures, but because their aim is to have everybody incorporate their design into ASICS or bunles that include custom assortments of peripherals and other add-ons.
Here’s the thing: I was building projects with Z-80 CPUs beginning in 1978, and could continue to do so today, because they and all of their required glue logic (then, 74LS244, 74LS374, and various shift registers, counters, and gates, today, 74HC series, backward compatible) are still available. I mean, I could literally build a new copy of my 1979 project, with no other changes other than slightly altered pinouts and voltages for EEPROMs to replace the EPrOMs I used then. In fact, I DID that in the mid-90s. I’d love to switch to ARM, or even better, RISC-V, to take advantage of the revolutionary advances in CPU design, but every company that builds ARM-based controllers and/or “microprocessors” makes their own custom blend, none of which are second sources for anyone else’s, and MOST of which will go obsolete in a few years, just because there are too many part types for anybody to keep track of, much less keep in stock. This is the business moel for all of the ARM chip makers: make every variation you can think of, and dump all but the most popular 5%. So what’s a mother to do? Just stick with 40-year-old 8-bit designs? (Well, okay, 16, since 68000s are still available as well, I think?)
Espressif is THE worst offenders when it comes to planned obsolescence. They made a one-off 32-bit CPU core that they put into the ESP8266, then they came up with a DIFFERENT one-off 32-bit CPU design for the ESP32, that from all I can tell, has orphaned every project ever designed with the 8266, and NOW they’ve come up with the ESP-32-c3 with a RISC-V core. Really? At least Apple lets us get settled into an architecture for a decade before dumping it and obsoleting all of our software.
This is why I HOPE i’m not a fool for putting a lot of hope in the RP2040 and its siblings that are sure to come. By making a part with wide appeal (or at most, a few such parts) that THEY CONTROL, we can hope that this will become a standard part that hobbyists will buy in great enough quantities to keep alive, and to ensure long term support for. I mean, I’m hoping this becomes the new ATmega328, because I’d love to have a cheap 32-bit chip that will stick around as long as the ‘328 has, which has happened mainly because of Arduino’s contribution to its popularity. My biggest concern is that when asked “why not RISC-V?” for the RP2040, they said, “because it wasn’t mature enough yet”. Which implies, I think, that there may be future RP microcontrollers with RISC-V cores, competing with and likely replacing the ARM core RP chips. But fingers crossed, MAYBE they will make the replacement parts feature-for-feature compatible (and, oh, dare I even think it, pin-compatible) with nothing changing but the CPU core so all I’ll have to do is recompile. I can hope.
Sigh.
Considering that you have frameworks and libraries that are compiled for many architectures, I don’t see how this is a problem. And let’s be honest: you can do way more now without being an expert than you could back then. Many stuff became architecture agnostic. If you want to code bare metal, well you have to know the platform well. But with all the abstraction layers available, well most of the time you just load a library for your I2C sensor that works with every architecture available to you and use it…
I agree. I like the variety and simplicity of microcontrollers post Arduino debut. This is when I started on electronics and learned a lot more about programming. I’m clearly not a pro, but this is my favorite hobby/lifestyle. I try to build things that can be upgraded with a little bit of hacking or just a code update, and don’t worry about if something breaks because rebuilding it is my idea of relaxing.
I’m not just talking about architectures – I’m talking about CHIPS. I’m talking about having to re-layout a PCB, or even redesign it from scratch because there is no available chip that does what the chip I chose ten years ago used. And just maintaining build workflows for multiple architectures IS a chore, so if I have old hardware and new hardware, I have to treat them differently. And don’t get me started on libraries and frameworks. Oh yeah, the new version of library X no longer supports architecture A, or at least, not if you’re building it on platform J. Pretending hardware is all the same doesn’t make it so.
Why does it matter if they are EOL? The parts you have still work. Things can continue the wy it is as long as you bought enough for a while. As for the series, I would only use industrial parts as they tend to have lifetimes of 10+ years. e.g. STM32F
I program in bare metal, I don’t have an issues of not being able to use ARM chips from different series or different vendors.
Becaue of SUPPORT. That’s what this whole article was about. If you have multiple versions of hardware, then every time you update your code, you have to validate it on all the hardware versions. Or don’t you ever validate your code?