Hardware choices are giving me a headache!


#1

I am doing LOTS of research on different hardware and software and what not for automation and data management and… I gotta say, I am so overwhelmed. Between Arduino, ESP(insertboardhere), RasPi and others and then tossing in POE connectivity, MQTT, Node Red, Firmata, VVVV and the other myriad of IoT crap out there, I am not even sure what direction to go now in the hobby. I know the decisions are all based on personal opinion and experience (of which I have none, opinion or experience) so those answers will probably be super diverse, but what hardware are you, the home automator hobbyist using? I have Arduino gear… Mega, Uno, Mini. I also have Pi3 and 3B. I have a bunch of ESP…now I can’t remember… boards. Okay, I also get that it also depends purely on what you are trying to accomplish with that hardware too. K.I.S.S is always better and unless you are going to integrate a number of tasks into one piece of hardware, there is no real reason to go all crazy. Like using a Mega to read only a temp/humidity module.

I guess what I am looking for specifically is this: What projects have you personally automated or made digitally controllable and what hardware did you chose for it and why? If you have set it up to be GUI managed…like a tablet on the wall with buttons for control… what did you chose to make that interface?

What prompted this is THIS project idea- I have put in my node/server closet in the new house and I know that once I put in the Plex server box and drives there will be some residual heat that will build up in there because it is all mounted above the entry door and there is no way for heat to escape… yet. I planned to put in a grill at ceiling height with a set of large computer case fans that are super quiet. I am thinking PWM speed control based on ambient temperature in the space, faster the hotter of course, and run it so the air is pulled from the floor up through an air filter to keep the closet air clean. The floor is a dirty place to be pulling air from obviously. I looked at an Uno to run PWM driver for the fans and a cheapo DHT(?) sensor and script to keep it simple. Then I dropped into the I2C rabbit hole and that was a days long spiral into technology, albeit simple still, and eyes rolled back into my head. Especially when I started looking at Firmata and the VVVV software?protocol?interface? (that looks incredibly complicated but admittedly super cool if you can figure out all of its nuances). I want upgradeability without a crap ton of hardware rebuilds but, ah heck, I know that every bit of this is continuing prototyping and updated versions ad nausium(grin). But where is the best place to jump into this curve? I have so far, bought a lot of different types of boards and component level stuff and analyzed into paralysis. Unlike most of my children, I am willing to listen to others experiences and avoid making the same mistakes.


#2

For the Arduino, ESP(insertboardhere), RasPi choice, I personally break it down like this; when I think Arduino, I think the 8-bitters, Uno and Mega, primarially, maybe a Leo for it’s USB, but my response to the Yun and it’s ilk are, WHY?!? (Except for the new FPGA stuff, that sounds very interesting.) The ESP’s, I view as Arduino with Wifi (which immediately also means bigger, too, after all the Arduino Ethernet boards have a bigger chip there driving the networking, too). If you need a small computer, then it’s RPi.

I go PoE (Arduino) wherever possible, and only Wifi (ESP module) if I have to — but never for anything that needs reliability, plus they need additional power (no one’s figured out PoW yet). However, all the Ethernet options are also rather expensive, so, I was just starting to put together my own bare-bones Arduino + P over RS485 design, when I realised Jon is prolly gonna want to put some smarts back in his light switches to drive those fancy new buttons of his, so I’ve been dragging my feet on it hoping to see what he’s doing, or, see if he comes out with an EtherBear first…

I²C and it’s ilk, I’d stick to sensors, personally, I’ve got an I²C temperature sensor hanging out my bedroom window, and I’ve seen people use it for network level stuff too, but, nah. I’m looking at RS485 as I said, and was looking at CAN too, for an alternative lighter-weight and cheaper networking layer than Ethernet; between the two, CAN is very nice, but seems to be limited to really tiny small message sizes, and I decided if I was going to invest in a protocol, I’d like just a little more flexibility, but I gotta say for direct connected simple messaging, I’ve always thought CAN looks like a really nice choice. However, it should be fairly easy to run MQTT over RS485, where I doubt you’d have much luck fitting MQTT packets into a CAN frame, which means a level of indirection I don’t want (but, if it was going to be there anyways, probably I would go with CAN).

Protocol wise, yup, I’ve been running MQTT which seems to still be the crowd favourite for reliable messaging — though, topic naming is a bit of an undefined swirly issue — but it’s still a nice common reasonably well aged simple protocol that will hook nicely into most of the automation systems around.

And of those, I’m playing with HA and Hassio, haven’t really gotten far in that direction myself, though, most of my automation is still in Python and BASH, so, still a bit behind the curve myself in that regard (I actually have a Hassio RPi sitting there powered and looking pretty, but not actually on the network because I haven’t felt brave enough to figure out how to get it to connect to the Wifi, and I’m out of network ports).


#3

I know where You are At! I started years ago and probably only in the past 12 months I have a setup that is fairly reliable and I’m not playing with every 5mins and break it… !

I think the key for me was once something is working and put into ‘production’ I needed to stop tweaking it :slight_smile: and make sure you keep copies of the code (ideally version controlled) I can’t count how many times I’ve had to spend too much time trying to work out which of my Arduino sketches is the one I had working on a specific device.

Basically what I ended up doing was selecting a automation server OpenHab2 and Arduinos, it doesn’t really matter what Arduino, just what you have lying around. I went with MQTT as it doesn’t require any additional plugins on OpenHab, just add an item with MQTT details. I enabled NodeRed on openhabian for rules as well.

My first projects:

  • A beam sensor on our driveway publishing to MQTT whenever someone passes it
  • Relay activating drive lights, rule setup when beam passes
  • Next up is a reed sensor on front door so drive lights turn on when door is opened
  • Couple of Temperature sensors

Above is working well currently and moving onto next projects (there are soo many!)

The above is my production setup which doesn’t get touched without careful planning or backups of rpi.

The really good thing with MQTT is that so many software solutions integrate with it out of the box, plus not really any issues running multiple systems.
Along side this I also have running a Domoticz, only due to it having an integration plugin for my alarm (this is why MQTT is excellent as if alarm was broadcasting MQTT it could have been integrated with OH2 without someone having to build a plugin). Also have Home Assistant running, both of these are to keep eye on development.

Also I have largely settled on ethernet.h library for sketches, keeping things constant makes setting up new projects a breeze as you copy 90% of needed code to get network/MQTT working.

Not sure if this is of any help but the key thing for me as mentioned was getting to a system running that works and isn’t being modified every 5mins. My desk is still covered in partly built projects though :wink:


#4

Fredderic and Kerry…

Thank you! I too have a list of projects a million miles long that I want to get into my production. Over a year ago, I boxed up my lab and put it all in a shipping container with all the rest of my house and embarked on a new property development project for my wife and I. Minus the house which is a manufactured home, I have done all the construction myself so I have put down thousands of feet of network cable and built multiple network nodes to connect it all together in preparation for being able to one day set my lab up again and get neck deep in home automation hobby stuff. I am now completing the home part of it so I will be able to empty out the contents of my 2 40 foot containers and turn them into a big electronics lab space. I am so ready to be able to get to that part of the plan.

I am starting really small with my fan automation project but I have a big list to add on to that.
Gate automation
Integrating that gate control with the house and camera system
Exterior lighting control
Motion activated hot water circulation system to the master bathroom (at far end of house from the heater)
ALL of the electrical in the new lab space… HVAC control, lighting, solder station air filtration remote control, and whatever else I can figure out to automate in there…
And if I can ever get to it, I want to put in a water feature thingy in the front yard that is lit up and has temperature monitoring and lighting on the system as well!

But first… I have to figure out the basics(grin). All of your advice is GREATLY appreciated.


#5

You just reminded me…

Where I would definitely consider using I²C, is within a unit to join parts together — same as it sometimes gets used on a large board, or over board interconnects, between board and front panel, and so forth. Like if that fan you’re wanting to control is in the same cabinet as the brains doing the controlling, but far enough away that you’re wanting to give it it’s own little driver board — like, because you don’t want to run PWM’d wires past all the other gear in the box, or something. There are various I²C extender chippies, undoubtedly some with PWM, so it would make sense to toss one of those and some supporting parts on a small board mounted next to the fan — trying to keep it fairly minimal — and run power and I²C down to the brain module. I²C was actually my second idea for the bedside control pad, because it’s built in to the ųC, and because of those IO extenders, but then, there’s those ATtiny’s…

And for figuring out the basics… Generally my philosophy has become, try to use the right tool for the job — but it doesn’t have to be THE RIGHT TOOL, just one that suits your needs, feels comfortable, and where possible (since this is a personal project) lets you do something just a little bit new! That was the purpose of stating how I break down the options. I started with an Arduino Uno desk clock. Then I stepped it up to an EtherTen based blinky lights project with a bit of E, and then Po’d it. Then I brought in an RPi and MQTT to control that, then I was going to use an ESP so I could have a small control pad on hand in bed, but I decided maybe the ESP with it’s Wifi (the Sonoff seems — according to one of those EM measuring gadgets the health nuts wave around — to be a little “harsh” with it’s emissions, compared to other devices like my laptop and phone), so I decided to postpone playing with the ESP for another project, and push up the RS485 instead (which then promptly got put on go-slow…). Along the way, I found I rather quickly out-grew the EtherTen’s program storage, so I had to upgrade it to an EtherMega, which free’d up the EtherTen so my clock can now stream its temperature sensors back to my controller (among other things), and I don’t have to set it’s time manually any more — it was also my expansion into integrating what were separate modules like an RTC onto the board. The revamp of my clock was going to involve ditching the Arduino board entirely, and being my first bare ųC project, but now I’ve shoved Ethernet on it, that’ll have to be something else, probably the bedside control pad — I’ve been using some RS485 modules, but that’s a prime candidate for merging with the Arduino. Which brings me to the point of this part … the first time I do that, will be with the Arduino chip still (I’ve got one pre-loaded with the Arduino firmware, even); part of the choice in hardware, was both easy entry (I hadn’t done any electronics stuff for about a decade, when I started this), but also an easy migration path. The chip at the heart of the Arduino is by all appearances dead easy to stick on a board by itself, where something bigger like the ESP (which comes in a module, so misses the point in this instance), or trying to roll your own RPi, is a very different story indeed.

Overall, though, it’s your project, you know where you are, and you’re the best judge of where you want to be … don’t be afraid to experiment and push your bounds, but try not to have to rip out the wiring of your house five times to achieve it (lots of different coloured ethernet cable is handy — just about anything can go over ethernet cable, just don’t cross the streams). Also try to expand your skills quickly, so you can fall back on better choices as you move into the “getting it all cohesive, useful, and reliable so my other half will let me expand into the rest of the house” phase. Jon and others have often mentioned the dramas to be had when things go wrong, and many many times have I heard of the need to consider the WAF (Wife Acceptance Factor).


#6

LOL… The WAF is definitely a major deciding factor in what happens to the house structure. I can wire the doghouse (mine, not the dog’s) anyway i want it to fail accidentally and I am the only one to blame. Her Highness on the other hand, has some very specific ideas about how things should work and how little interference I should be creating in her ability to just “flip the switch”. I will give her that. I don’t need my underwear unexpectedly starched as a payback for an ill-planned “reboot the lightswitch” comment.

I have overbuilt the heck out of my point to point wiring… like 4 CAT5E cable runs from one node point to another, even though I can only connect one cable at a time to the actual network backbone. But I have lots of redundancy and possibilities for dedicated camera lines, PoE (homebrew or legit 802.3AF) and even a secondary network if that ever becomes a “thing”… oh , I hope not. And when I actually wire up switch points and things in my auxiliary structures, I will build in 3 sets of CAT5E just because its cheap and easy.

Your advice on CAN and i2c makes a lot of sense. Makes ‘within device’ communication cleaner and keeps all the EM producing stuff further from the fiddly parts that don’t like it. I have pretty much narrowed it down to Arduino devices for device control and the RpI for management of all the messages (OpenHab and Node Red). The Arduino libraries seem to be ridiculously plentiful so cut and paste programming is easy to achieve. It’s time now for me to just get elbows deep in it and build based on that platform topology.The add on cards or hats to get stuff done with Arduino are just as plentiful so no reason to reinvent the wheel.`