The #1 reason that I can think of is if you need a massive number of GPIO pins. Nothing comes close to what a MEGA can provide.
The #2 reason would be if you want to use a hard-wried RJ45 Ethernet connection instead of WiFi. Much easier to add a hardwired connection to an UNO/MEGA then it is on an ESP8266/ESP32 board.
It is possible, for sure. If you want to try to help test that theory, all you need to do is make a very simple edit to your copy of the SmartThingsEthernetW5100.cpp file as shown below.
At the very bottom of the file, you'll find
while (st_client.connected()) {
//while (st_client.available()) {
char c = st_client.read(); //gets byte from ethernet buffer
//if (_isDebugEnabled) { Serial.print(c); } //prints byte to serial monitor
//}
}
Try simply changing it as follows
//while (st_client.connected()) {
while (st_client.available()) {
char c = st_client.read(); //gets byte from ethernet buffer
//if (_isDebugEnabled) { Serial.print(c); } //prints byte to serial monitor
//}
}
Please report back your findings and let us know if that resolves the issue you've been seeing.
Thanks!
Cool. I'll certainly do that. Thank you 
I have some free time thanks to the "working from home" mandate. I am going to try and tackle writing a hubduino addressable LED sketch. My plan is to have two main elements: Routines and Palettes. Ideally, these would be dynamic within the hubitat driver. Additional variables such as speed, master brightness, auto cycle, duration, random, etc. could be implemented as well.
I have confidence in being able to write the C++ uC code, but very little for the groovy driver.
Is it possible for a list of available routines and palettes to be passed to the hubitat child driver?
If so, would these be available in a dropdown type menu to be able to control the device?
Would a tile work, and if so, which template?
I would hate to do all this work and not have a good way to control it.
There isn't an existing template that allows for that. As far as "routines" or "palettes", if you want to stick to standard capabilities, you can use the "Light Effects" capability. This would probably pair best with routines or patters. There really is no attribute for "palette" that would work but a custom attribute wouldn't be difficult. However, that means you would not be able to control that from a dashboard. So, I'm not quite sure what you were thinking about the control capabilities.
What library are you using as the basis for your sketch? FastLED? WS2812FX? I have a LOT of addressable LEDs in the house using a lot of different control method. I also still have a lot of extra parts so if you need anything tested, I'd be happy to try it out for you.
If you're looking for some help on the groovy side, I can defintiely try to help you there. We would just have to determine what commands you're looking to send from Hubitat for each of the different aspects you'd have to map to.
Planning to use the FastLED library. Only dashboard template I found that may work is Color Bulb. What template uses "Light Effects"? I could definitely use that for "routines" and could write an algo that matches (or creates dynamically) a palette that is closest to the RGB value sent.
I think the biggest challenge is going to be the dashboard control. (the Achilles' heel of HE)
Can you expound a bit on some of the various ways you are controlling aLEDs?
Edit:
I found this: Driver Capability List - Hubitat Documentation
and this thread that may help: LightEffects
Then how would you just get a solid RGB color? Or are you only planning on implementing effects and not solids?
solid color could be a Light Effect. If so, then match the RGB value. Else, select closest pallette.
Not sure how it should or will work yet. The key will be how to control it with the very limited dashboard options.
Yeah, i can't think of how you would do this from a dashboard that would be workable.
Getting a compile error
Multiple libraries were found for "Servo.h"
Used: C:\Users\Doug\AppData\Local\Arduino15\packages\esp8266\hardware\esp8266\2.6.3\libraries\Servo
In file included from C:\Users\Doug\Documents\Arduino\libraries\ST_Anything\PS_Power.cpp:35:0:
Not used: C:\Program Files (x86)\Arduino\libraries\Servo
C:\Users\Doug\Documents\Arduino\libraries\ST_Anything\PS_Power.h:38:21: fatal error: EmonLib.h: No such file or directory
Not used: C:\Users\Doug\Documents\Arduino\libraries\Servo
#include "EmonLib.h"
^
compilation terminated.
exit status 1
Error compiling for board LOLIN(WEMOS) D1 R2 & mini.You’ll need to look further up in the compilation debug window. The messages you posted above about multiple servo libraries are just informational. I have seen that many times. Something else is throwing an error earlier in the build, I believe.
Also, did you add ALL of the Arduino libraries from my GitHub repository? The emon library is included in my repository.
Dan, I wish I was 1/4 as smart as you. I had recently updated my Arduino IDE. Many libraries were missing, so I simply copied the libraries again from the github master, and it works. Dumb mistake on my part!
Perhaps there's a better solution for security, but I'm looking for a means of getting oauth2 authentication between an ethernet connected arduino and hubitat. Is that easily doable with the st_anything framework? If so, any tutorials available?
Security is kind of important for this as it will be used for both a deadbolt control and a garage door.
Hubduino doesn't use OAUTH because the boards have to be on the same local network as the hub. Hubduino passes messages to the Hub using port 39501. That is the port designated to receive unsolicited HTTP messages. The message is then passed off to the Parse method of the device with a device id that matches info in the header of the message, like the MAC address or the HEX IP address. That's how it's able to pass info back from the board to the hub without waiting for the hub to request it. And since it's on your local network and it's only using a driver, no OAUTH is needed.
OAUTH can only be used in apps, not in drivers.
What are you worried about? Someone getting onto your network and figuring out the IP address of your board and then figuring out the necessary POST URL to use to open the garage door? I think it's much more likely that someone would just break a window or kick your door down rather than hack all of that.
If I understand your request correctly, you'd prefer to use encrypted communications between the microcontroller running ST_Anything and the Hubitat Hub. Is that correct?
If so, unfortunately the answer is that ST_Anything/HubDuino does not support encryption of the data over you LAN. Some Arduino boards do not have the memory or CPU resources required to implement modern encryption schemes. These are very lightweight, inexpensive micro-controllers. Since the data is all local to your LAN, the security risk should be relatively low, as @Ryan780 pointed out above.
Some of the more modern Arduino/ESP microcontrollers do support HTTPS communications. However, I do not feel this is necessary at this time due to the risk and demand for this functionality being relatively low.
I make a decent living being paranoid about security 
As a former network engineer and current cybersecurity engineer with a bad case of OCD, it comes with the territory.
Understood. I've only started with Arduino about a week ago with two cheapo (paid $5 each) NodeMCU that seems to do TLS. Just connected it to a remote system I chose based on its support for AES-128 encryption, four relays, and tiny keyring size four button remotes that cost $6 each for replacements. Oh, and did I mention very good range with no joining/routing issues inherent to z-wave or zigbee too? (Main reason I'm not using one of those; tried a few, didn't like any of them.)
For people who say that somebody could kick in a window or a door, that's missing the point. That method of entry leaves evidence of a break-in, meaning any theft is covered by insurance. Something like a remote replay attack to open a door does not leave evidence and, therefore, is likely not covered. This is also a reason I make sure my locks aren't easily susceptible to bump keys.
Curious, what is the advantage of this over using the Maker API? I.e. speed, compatibility with older arduino boards, etc. I'm very new to arduino (and hard hacking period) so I'm still soaking all of this in. It's all shockingly easy to learn BTW, in retrospect I'm not sure why I dismissed this approach to stuff earlier, especially given the advantages that PoE offers.
You would have to program into the Arduino all of the device IDs and then all of the commands. Using a custom driver allows every thing to be standard and easily implemented. You can set up a new Hubduino board in about 3 mins once you get some practice. It would take a lot, LOT longer to set up every device as a virtual device and then set up each of the devices in your board with the appropriate device number.
Also, this method allows for 2 way communication between the hub and the board. The maker API is one-way. So, you'd also have to have a custom driver to send stuff back to the board.
Take a look at the ST_Anything libraries. It's really rather astounding how connected and organized and simplified everything is. You can literally set up a board with any combination of devices you want without having to do anything custom. It's all plug and play.
I'm not seeing any interrupt driven events in the nodemcu sketch; how responsive does the hubitat end up being with this setup? Or is that buried in the libraries somewhere?
EDIT: Nevermind, it is
Download the Hubitat app
