Hubduino Question

Hi, I am just starting with Hubitat moving from a VeraPlus (so no smartthings experience).

I have a MySensors system connected to my VeraPlus and expect I will eventually migrate to Hubduino.

I've looked through some of the documentation and see a number of "device" types listed.

So as I am thinking for the future can I ask what level of sensor programming freedom is there on the "arduino" side? For instance, if I built a special level sender that used some processor resources and maybe an A/D or a timer or so. Would I be able to send the info to Hubitat? Would be OK if it were recognized and something else (such as voltage) on the Hubitat end.


Yes, you have total freedom to write as little or as much custom code as you’d like. My son and I wrote the ST_Anything Arduino library to make using the old SmartThings ThingShield easier. Once ST discontinued the ThingShield, I added LAN-connected device support as well.

There are actually two main Arduino Libraries (each with a set of sub-libraries) that make up ST_Anything.

The first is the “SmartThings...” set of libraries. It has its own ReadMe file. It handles all two-way communications between the MCU and the Hub. It simply sends and receives strings. It can be used with any Arduino sketch.

The second is the “ST_Anything...” set of libraries. It uses the “SmartThings...” libraries to handle communications. It has a set of C++ classes that implement each device. And it has a scheduler that handles keeping every device up to date. Adding custom classes for new devices is pretty straightforward if you’re an experienced C++ developer.

There are some features that we’ve built into the design that allows some amount of “local processing” directly on the MCU. Once you get around to giving it a try, feel free to reach out and ask me anything. I am happy to help out.

BTW - What device’s are you currently using with MySensors?

One more thing... HubDuino is really just the Device Drivers for Hubitat to support the Arduino code. All of the Arduino code is the same, regardless of whether you’re using Hubitat or ST.


Hi Dan, thanks for the kind reply.

Current MySensors: water sensor, furnace lockout detect (switch) and my main usage is an ultrasonic fuel oil level sensor. The fuel oil sensor is not ready for prime time but it was the application that started me looking at MySensors.

I am not a C++ programmer. I'm probably be considered a fair coder in embedded C. Programming is not my profession. However I am good with overall system design. I prefer C over "arduinoese". Your description sounds great and I look forward to getting started with it.

If you don't mind me asking, What ESP board (or other board) would your recommend for a battery operated device. I guess it would be wireless ethernet. Cost is not an issue here as all the boards are pretty inexpensive.


Hmmmm... WiFi and battery powered don’t usually go too well together. I know of at least one user who was able to make it work using the ESP’s deep sleep function. To do so, the MCU wakes up infrequently (like once an hour), connects to WiFi, scans an input, sends an update to the hub, and then goes back to sleep. It really only works for a device that only sends data. The model of micro controller will depend on the type of device attached (e.g. do you need an analog input?) Personally, I like the inexpensive NodeMCU ESP8266-12e boards. They can be bought on Amazon for less than $9. For a tiny solution, the ESP-01 is a fun choice if you only need 2 digital I/O pins. They are more work to get programmed and powered, though. That why the NodeMCU boards are recommended.

Two-way communications requires constant power to maintain the WiFi connection so it can listen for incoming requests.

I actually have support of an ultrasonic level sensor already. Hopefully yours is the same model as the ST user who added it. The Ultrasonic Child Driver (groovy) has some options to convert distance (from the sensor) into a volume of the tank. You may have to tweak the math based on your specific tank geometry.

Thanks again for the reply.

My ultrasonic is likely custom. I already have it coded for an Arduino Pro mini so I'm not worried about that. As for the batteries I had planned on on shutting down most of the time. The current water sensor (I'm using it for a test of concept) has been running for about 3 months on 3 AAA carbon batteries. I would expect with WiFi the on time will have to be longer.

It might be interesting if I could use the RFM69 905 Mhz radio to send data to a NodeMCU board then use your Hubduino to go to HE. I'll have to think about that.


1 Like

Have you seen this Laser device used for liquid?

Someone around here is using this for their Swimming Pool water level sensing. They cut a skimmer sized circle of thin white plastic as a reflecting surface with this laser and a Particle (If I remember right) attached to the inside of the skimmer lid. I remember it because he was quite vocal about how much better it was than other attempts, such as ultrasonic.

This is the ultrsonic sensor some other users have successfully implemented with ST_Anything.

And here is the thread where I helped another user work through implementing it...

Thanks folks (guys?) for the kind suggestions!

I spent some time in the automotive industry developing an ultrasonic fuel level sender for gas/diesel fuel level measurement. When I left it had only been in production on the Bugatti Veyron and Ford GT, maybe more by now I'm not sure.
Anyway it makes me want to roll my own so to speak.

But I very much appreciate the suggestions. I shows how helpful folks are in this forum. Having said that, It makes me realize since I've been part of this forum I've seen no bad behavior. A breath of fresh air!.




Hi, I'd like to report I have an ESP8266-12E Amica up and running using the Alarm sketch. That is if you call sitting on the end of a USB cable running.

One question regarding the MAC address assignment. In your write up you suggested using a MAC address starting with 06. However to the best of my knowledge the user has no control over the MAC address selection. Am I missing something?

Thank you very much for our effort in making this possible :grin:


1 Like

Up and running on the workbench counts in my book. Congratulations!

As for the MAC address question...
Only if you're using an Arduino with a W5100 or W5500 shield. The NodeMCU ESP8266 boards have their MAC addresses defined in the hardware, so nothing to edit in the sketch for those boards.

From the ReadMe...

  • *** NOTE: If using the W5100 Shield, YOU MUST ASSIGN IT A UNIQUE MAC ADDRESS in the sketch! Please leave the first octet in the MAC Address '06' as certain MAC addresses are UNICAST while others are MULTICAST. Your MAC must be UNICAST and be a 'Locally Administered Address' Please see MAC address - Wikipedia for more information ***
  • *** NOTE: If using the W5500 Shield, YOU MUST ASSIGN IT A UNIQUE MAC ADDRESS in the sketch! Use the one packaged with the W5500 shield.


Thank you for Hubduino and thanks or the response. I guess I didn't get that not 5100 and not 5500 meant it didn't matter. A lesson learned.


1 Like


Hi, I have a Hubduino successfully employed using the alarm demo as contacts only.

Now I want to get a ST_Generic version working.

I started with "ST_Anything_AlarmPanel_ESP8266WiFi.ino"

changed to #include "Constants.h"
added #include "PS_Generic.h"

Copied PS_Generic.cpp and PS_Generic.h into the arduino ino directory also constants.h

Now I can compile only if I rename PS_Generic.cpp and PS_Generic.h to something else.

I'm guessing this is a #include <> vs #include "" but I can't find it.

Any suggestions of what I missed?


My error is:

C:\Users\john\AppData\Local\Temp\arduino_build_97635\libraries\ST_Anything\PS_Generic.cpp.o: In function `st::PS_Generic::~PS_Generic()':

C:\Users\john\Documents\Arduino\libraries\ST_Anything/PS_Generic.cpp:49: multiple definition of `st::PS_Generic::~PS_Generic()'

I wouldn’t move the files around. Leave them in their normal locations.

The PS_Generic class was created and added by another SmartThings user. It is meant mostly as a template, I believe.

If you can describe what you’re trying to do, I’d be happy to help explain the best way to use HubDuino.


I'm trying to send a single character as a string or hex to my Hubitat. There I can decode it to whatever I want. I have part of my system working with the alarm panel using each contact as a binary char but this is just too clunky.

Curious about the need to leave the cpp and h files in the library folders. In the PS_Generic.cpp it says
" // Here is where you would do whatever you need to do to get your data. "
so I assumed it should be moved to the project folder because I don't like changing library files.


Your instinct about not changing library files is a good one. In this case though, by copying those files you’re creating duplicate classes which causes a conflict. You can MOVE the files to the local sketch folder if desired. Or simply copy and rename them and change the name of the internal class to avoid conflicts.


Thanks. So is using the PS_Generic the best way to transfer a single char or hex?


Not for a single character...

How are you generating the data that you want sent to Hubitat? If you’re not using any of the normal/traditional ST_Anything class objects/devices, there may be a simpler method to communicate with Hubitat via an Arduino/ESP8266.

1 Like

Actually I'm using an arduino mini for now and discrete pins from the mini to the ESP8266. I hope to make this more elegant in the future.


Okay. I think you’d find it simpler to use my SmartThings communications library for the ESP8266 instead of using ST_Anything.

Tomorrow I’ll whip up a simple sketch and Hubitat driver. How do you plan on using the data within Hubitat? That will determine what Capabilities are needed in the driver.

Thanks so much.

Yes one part of my goals is to have a Hubitat device attribute that can be changed by the pro mini (based on a number of things).

I then can use this attribute in the Hubitat dashboard to notify the family of a number of conditions at home.