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!
1 Like
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.
1 Like
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.
1 Like
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
ST_Anything was originally written for SmartThings in late 2014, long before Hubitat existed. SmartThings originally had an Zigbee Arduino shield called the ThingShield. This allowed simple ASCII Text bi-directional communication between an Arduino and the SmartThings Hub/Cloud. ST_Anything simplified the process and drastically reduced the requirement for writing custom C++ code on the Arduino, as well a Groovy code on SmartThings. Eventually, SmartThings stopped selling the ThingShield. At that time, I added support for LAN connected devices to keep the project alive. Since then, it has thrived with the availability of very low-cost, reliable, WiFi microcontrollers like the ESP8266 and ESP32.
When Hubitat was released back in Jan/Feb 2018, I quickly jumped over to the new platform and HubDuino was born. The Arduino libraries remained basically the same, while Groovy Hub code required some changes due to the differences in the two platforms. At that time, Hubitat did not even have the Marker API App.
Since then, I have pondered the exact question you posted... Why not just use the Maker API? I would like to use it, as a standardized means of communications with the hub, however it is lacking in a few areas. The biggest issue is the fact that there is no way for the automatic creation of the necessary virtual devices to support all of the 'devices' that one defines within the Arduino sketch. As @Ryan780 pointed out above, it would be a very tedious effort to manually create all of the virtual devices, and then obtain their device ID's (which could be queried via the Maker API, though... 
), and establish communications. The sketch would also have to submit a POST request to configure the Maker API's "URL to send device events to by POST" to have updates from Hubitat automatically sent to the Arduino sketch. Doing so would establish two-way communications. Since the goal of HubDuino/ST_Anything is to make things as simple as possible for the end users, this seems like the wrong direction at this time.
I do thing for many custom Arduino sketches, Raspberry Pi programs, etc..., the Maker API is the correct solution for two-way communications with the Hubitat Elevation Hub. However, HubDuino/ST_Anything will continue to use its existing Parent Ethernet and Parent ThingShield drivers to dramatically simplify this process for users. The communications between my Arduino libraries and the Hubitat drivers could, and should, be updated to follow standard RESTful API guidelines. When I wrote the LAN-connected support, I was unfamiliar with exactly how RESTful API's and JSON worked. I was just thrilled to cobble together a working solution! 
Looks like you've answered your own question already... Just wanted to say that the ST_Anything libraries do not usually make use of true interrupts on the microcontroller. Instead, digital inputs are scanned every pass through the loop() routine of the Arduino sketch. This ensures compatibility across a large number of Arduino compatible hardware boards, and keeps the code simple. True hardware interrupts are implemented for some hardware devices, like the PS_PulseCounter device, to keep an accurate count of high-speed pulses from devices like paddle wheels for measuring water flow or wind speed.
All communication between the micro-controller and the hub occurs immediately as needed. The hub does not poll the Arduino, nor does the Arduino have to poll the hub. This minimizes LAN traffic and the workload on both devices. Also, there is a built-in automatic 'refresh' that occurs every 5 minutes, where the Arduino sends a status update to hub, just to make sure the state of all devices attached to the Arduino are kept up to date on the hub in the event of a communications problem (e.g. a device on the Arduino changes state while the hub is being rebooted for a firmware update.) This 5 minute interval can be adjusted in the constants.h file, along with other user adjustable parameters/features.
I hope this helps you understand how HubDuino/ST_Anything works and how it came to be in its current form over time. If you have any other questions, please feel free to ask.
Dan
2 Likes
This would mean you could only have one board connected to Hubitat at any one time since you can only send the POST request to one URL.
Not exactly... you can install multiple copies of the Maker API App on a single hub. So each microcontroller could talk to its own Maker API instance.
That seems a heck of a lot more complicated to me.
Can someone confirm that the ST_Anything_RGB_ESP8266Wifi,ino sketch works?
I update the usual, IP of device, hub, etc... comment out ST hub port, uncomment HE port. Change Anode boolean to true. I get it to compile, Add device to HE, it finds it and adds the child.
All three LEDs are full on, and cannot control them from HE. I have loaded an ESP RGB tester, and the board PWMs all three as expected.
Not sure what is wrong. EX_RGB_Dim.h and .cpp are unmodded.
Doug,
Unfortunately, I cannot confirm that it works. The RGB and RGBW support was added by a SmartThings user a few years ago.
Can you monitor the Arduino IDE Serial Monitor Window, as well as the Hubitat Live Logs, while you attempt to command the board via the Hub's Device Details page? Perhaps something will become obvious once you see what is going on with the data.
One hypothesis is that there is a difference between how SmartThings and Hubitat handle Color. So for example, if you're trying to send a command via Rule Machine, perhaps the color values are getting mixed up? If this hypothesis is correct, then the RGB and RGBW Child Drivers would need to be tweaked accordingly. Again, this is only a hypothesis that I just came up with.
Although my own code uses true interrupts for the particular event I need to receive, which is technically better, that doesn't seem to make any real world difference in my particular use case due to the hardware that I'm using to talk to the arduino. Interrupts are easy enough to weave into Dan's solution if I really need them, but right now I don't need to. It just works as is.
Saves me a lot of time indeed, thanks for this!
As for the security model I originally alluded to, I think the easiest path to get there is just use one my leonardos with an ethernet shield, and enable dynamic arp inspection. Costs about $20 more worth of hardware to do that than nodemcu, but it's something I would prefer anyways as I just don't like using wireless on any kind of a fixed point device, mainly for reliability concerns. (Sorry, I'm just racist against wifi 
even though I rely upon it for mobile stuff.)
There doesn't seem to be anything requiring a one-to-one relationship, just so long as both arduinos have the correct API key, you should be good to go.
