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.
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.
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.
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.
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
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.
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.
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.
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.
