How am I going to learn anything if you do all the work? 
Thanks for this. I'm going to start parsing through it and learn something,
EDIT: I read through all of your README, and a few dozen Arduino example sketches. Seems pretty straight forward. Looking forward to giving it a go, because if I get this working I still have an ultrasonic level indicator I want to stick on my pool bleach tank.... 
OK, might need a pointer. The sample Mega sketch you gave compiles fine - no issues there.
However, I thought I would play with the ESP8266 I have on-hand while I'm waiting for the Mega to arrive.
I can't get any of those sketches to even compile. Clearly something I'm doing wrong, but not sure what.
I tried loading "ST_Anything_Multiples_ESP8266WiFi", changing board in the IDE to "Generic ESP8266 Module" and verify, and right off the bat I get:
exit status 1
'D7' was not declared in this scope
I assume either the pin definitions were supposed to be loaded and weren't, or I was supposed to manually add them in the sketch but didn't.
If I remember correctly, you should be using NodeMCU 1.0 (12E) or something similar to that.
I got it to load with Generic ESP8266 after uncommenting the pin assignment constants in the code. Now to make it actually do something useful.
That is correct. All of my ESP8266WiFi example sketches were written for the NodeMCU 1.0 (12E) board.
When you choose a specific board from the boards manager menu, hardware specific include files are automagically included which have hardware specific definitions. In the case of the NodeMCU boards, the D0 - Dn pins are defined that match the silkscreening on the board. This makes it much simpler to know how to wire things up. This is why those pin definitions are now commented out in the sketch. Other similar boards also use the âDnâ nomenclature, so I did not want my sketch to override those other hardware specific definitions.
That makes sense. I just went and looked, and sure enough the pins_arduino.h is different on the Generic ESP8266 and NodeMCU.
Wasn't obvious to me that I had to select NodeMCU as the board type. I got it now.
Thanks!
Well, got the ESP8266 working with my capacitive level sensor (the only sensor I had lying around). I brought it into Hubitat as a contact sensor, but maybe should have picked something more representative (water sensor or generic sensor maybe??).
It was too easy to setup and worked 1st try, so now have extra time to kill. 
Off to play Outer Worlds.
Nice job, very cool/easy to use set of code. 
Got one of my MEGA 2560 boards over lunch.
Your example sketch worked great (except one typo - "contact12" was in there 2x, instead of "contact13"). I appreciate you making sure there was a bug to see if I was paying attention/learned anything.
I haven't tested the siren output yet, but have the relay... So maybe this weekend!
LOL! Yea, glad to see you're paying attention!!! 
Nice. Depending on the relay (active LOW or active HIGH), you may need to tweak the constructor parameters for the EX_Alarm device in in the sketch.
Yup, same with the motion sensor (I don't have one of those handy to test on the bench). Should be simple enough, though!
EDIT: Oh, and I also ordered two 8 channel 12v to 5v opto isolator/coupler boards too... Those are coming from China, though, so maybe a while.
I figured I'll just eliminate any chance that voltage from the inputs was killing my other boards, and install isolators.
So, when I run contact sensors, I do not use any external power supplies or pull-up resistors. I simply connect one side of the contact sensor to the corresponding GPIO pin, and the other side to the Arduino's GND pin. By default, my example sketches enable the internal pull-up resistor feature of the contact sensor input pins. This means they will supply +5VDC via the Arduino board itself to the contact sensor. When the contact sensor is closed, it will short the input to Gnd. When the contact sensor is open, there will be 5V on the pin. Thus guaranteeing either a HIGH or LOW signal. I have used this design without fail for 5+ years. The Arduino's 5VDC voltage regulator is capable of handling the few milliamps per GPIO pin that this design utilizes.
Since you mentioned that your old 12V alarm panel has been removed from the equation, I would think you could also follow the above wiring design.
I do use a regulated 9VDC power supply to power my Arduino MEGA 2560 via its barrel-style power connector. Here is the power supply that I am using. So far, so good!
I did once lose an Arduino UNO + SmartThings ThingShield (Zigbee) during a very close lightning strike. I don't know of any simple way to deal with lightning, as all of those wires make pretty good antennas that easily pick up the EMF from the lightning and can fry electronics. I also lost a router, a network switch, and numerous network ports on various devices (Xbox 360, home server, my son's computer, etc...) It was a very bad day...
https://www.amazon.com/gp/product/B00EJR7A9Y/ref=ox_sc_saved_title_7?smid=A1SBX6SNS064WP&th=1
Oh, it would definitely work that way - and does work that way with my window/door contact sensors on my bench with the arduino providing the 5V.
However, that approach doesn't really provide any ESD protection, and home alarm contacts are notorious for getting some pretty serious voltage spikes during lightning storms, etc due to no ground present and long limited jacket insulation wiring runs.
That is why Konnected had to come up with their diode solution in a hurry - quite a number of customers started losing boards during lightning storms from voltage pikes on the sensor inputs.
It is also why purpose built alarms panels all have ESD protection on the inputs.
Anyway, opto couplers are <$1 each anyway, so not a large cost to implement. The boards I bought w/8 channels of optical couplers was ~$10 mounted on PCB.
You could create your own board with a handful of parts with sockets for the Opto-isolators. When / if they get blown out, pop in a new one and away you go :))
I thought about that.
I'm good with IC/DIP layouts on breadboards - which would likely be fine for an alarm panel as I have plenty of room, limited access, limited vibration), but have more issues when moving over to prototyping as I I'm a crappy solderer.
I am just the opposite LOL
Got all of it setup last night except the alarm siren (ran out of time, and didn't want to test the siren at 10pm ).
I'm having a hell of a time getting the stupid thin wired diodes to not fall out of the cheap ass breadboard I have on hand, so I may have to solder everything after all...
I also had to tweak the motion sensor input config to make it work, but that was simple enough.
Thanks for everyone's help. Even with buying some extra boards (mostly to tinker with), it was still tremendously cheaper than buying the Konnected Pro 12 board, and I got a lot more than 12 channels (which is what I really needed) - granted, at the cost of my time and engineering know how.
I still recommend the Konnected board for someone that wants it to be simple/easy to implement in a pre-packaged offering.
EDIT: Got the siren hooked up, too. All sensors and siren are working.
Got my throw-in level transmitter today...
https://www.amazon.com/gp/product/B07SPWPVFH
https://wiki.dfrobot.com/Throw-in_Type_Liquid_Level_Transmitter_SKU_KIT0139
So I'll either use the capacitance level sensor, or this... Haven't decided yet.
@ogiewon Quick question - I don't like the lastUpdated polluting my event log so was going to remove it from the driver, and instead continuously overwrite a new "wasUpdated" attribute with the same value to ensure the device last activity gets updated (which I use to tell if a device is alive or dead), but no event is made.
I looked in the drivers and the parent code and didn't see that you were using those values anywhere, but thought I would ask before I removed it.
Totally understand. That attribute was added by another user on the ST platform, with its massive cloud server platform.
That attribute is purely optional from a HubDuino perspective.
It's not a bad idea to write to something periodically to keep the Last Activity field updated (for watchdog use, etc).
So I did:
attribute "wasUpdated", "String"
Then in the parse:
// Update wasUpdated
sendEvent(name: "wasUpdated", value: "true")
That way Last Activity gets updated each time it parses something, but doesn't make a new event. Because otherwise with some things (like window contact sensors) they almost never change and you don't know if they are updating or not.
Download the Hubitat app
