[Release] HubDuino v1.1.9 - Hubitat to Arduino / ESP8266 / ESP32 / ThingShield Integration (ST_Anything)

You do know Konnected is supported on Hubitat? Just checking...

Using HubDuino, you can very easily use the IS_Motion device to implement a motion sensor. No need to use a IS_Contact sensor for that.

Take a look at the following example sketch to help get started.

Dan, I briefly tried using an IS_Motion device but without success. Didn't behave the same as a contact. I saw something in the console about a 30 second calibration period and figured that the IS_Motion device is meant for devices that behave differently from a simple on/off pattern.

You can safely use the motion device. It does have a 30 second startup pause on reboot, but you can ignore it. It doesn’t really do anything other than wait 30 seconds before sending the initial update. Afterwards, it is just as responsive as the contact sensor.

The 30 seconds is in there to allow PIR motion sensors time to settle upon power up.

Update: You will need to tweak the parameters passed into the IS_Motion constructor to enable the internal pullup resistor and to set whether to trigger on HIGH or LOW. Read the documentation in the top section of the .h or .cpp file to the IS_Motion device for details.

Need some help....getting the following error in my code below:

C:\Users\aaron\Desktop\ST_Anything-master\Arduino\Sketches\ST_Anything_Relays_ESP8266\ST_Anything_Relays_ESP8266.ino:145:33: note: in expansion of macro 'F'

 static st::S_TimedRelay sensor3(F(“relaySwitch3�), PIN_TIMEDRELAY_3, LOW, true, 1500, 1, 1);

                                 ^

Multiple libraries were found for "Servo.h"
 Used: C:\Users\aaron\Documents\ArduinoData\packages\esp8266\hardware\esp8266\2.3.0\libraries\Servo
 Not used: C:\Users\aaron\Documents\Arduino\libraries\Servo
 Not used: C:\Program Files\WindowsApps\ArduinoLLC.ArduinoIDE_1.8.15.0_x86__mdqgnx93n4wtt\libraries\Servo
exit status 1
stray '\342' in program

//******************************************************************************************
// File: ST_Anything_Relays_ESP8266.ino
// Authors: Dan G Ogorchock & Daniel J Ogorchock (Father and Son)
//
// Summary: This Arduino Sketch, along with the ST_Anything library and the revised SmartThings
//          library, demonstrates the ability of one NodeMCU ESP8266 to
//          implement a multi input/output custom device for integration into SmartThings.
//
//          The ST_Anything library takes care of all of the work to schedule device updates
//          as well as all communications with the NodeMCU ESP8266’s WiFi.
//
//          ST_Anything_Relays_ESP8266 implements the following ST Capabilities as a demo of what is possible with a single NodeMCU ESP8266
//            - 3 x Relay Switch devices
//
//
// Change History:
//
//    Date        Who            What
//    ----        ---            ----
//    2015-01-03  Dan & Daniel   Original Creation
//    2017-02-12  Dan Ogorchock  Revised to use the new SMartThings v2.0 library
//    2017-04-17  Dan Ogorchock  New example showing use of Multiple device of same ST Capability
//                               used with new Parent/Child Device Handlers (i.e. Composite DH)
//    2017-05-25  Dan Ogorchock  Revised example sketch, taking into account limitations of NodeMCU GPIO pins
//    2017-11-27  Kai Lenk       Modified to 3 relaySwitch
//    2017-11-29  Dan Ogorchock  Revisions to make sure works for Kai Lenk
//    2018-02-09  Dan Ogorchock  Added support for Hubitat Elevation Hub
//
//******************************************************************************************
//******************************************************************************************
// SmartThings Library for ESP8266WiFi
//******************************************************************************************
#include <SmartThingsESP8266WiFi.h>

//******************************************************************************************
// ST_Anything Library
//******************************************************************************************
#include <Constants.h> //Constants.h is designed to be modified by the end user to adjust behavior of the ST_Anything library
#include <Device.h> //Generic Device Class, inherited by Sensor and Executor classes
#include <Sensor.h> //Generic Sensor Class, typically provides data to ST Cloud (e.g. Temperature, Motion, etc…)
#include <Executor.h> //Generic Executor Class, typically receives data from ST Cloud (e.g. Switch)
#include <InterruptSensor.h> //Generic Interrupt "Sensor" Class, waits for change of state on digital input
#include <PollingSensor.h> //Generic Polling "Sensor" Class, polls Arduino pins periodically
#include <Everything.h> //Master Brain of ST_Anything library that ties everything together and performs ST Shield communications

//#include <PS_Illuminance.h> //Implements a Polling Sensor (PS) to measure light levels via a photo resistor

//#include <PS_TemperatureHumidity.h> //Implements a Polling Sensor (PS) to measure Temperature and Humidity via DHT library
//#include <PS_DS18B20_Temperature.h> //Implements a Polling Sesnor (PS) to measure Temperature via DS18B20 libraries
//#include <PS_Water.h> //Implements a Polling Sensor (PS) to measure presence of water (i.e. leak detector)
//#include <IS_Motion.h> //Implements an Interrupt Sensor (IS) to detect motion via a PIR sensor
//#include <IS_Contact.h> //Implements an Interrupt Sensor (IS) to monitor the status of a digital input pin
//#include <IS_Smoke.h> //Implements an Interrupt Sensor (IS) to monitor the status of a digital input pin
//#include <IS_DoorControl.h> //Implements an Interrupt Sensor (IS) and Executor to monitor the status of a digital input pin and control a digital output pin
//#include <IS_Button.h> //Implements an Interrupt Sensor (IS) to monitor the status of a digital input pin for button presses
//#include <EX_Switch.h> //Implements an Executor (EX) via a digital output to a relay
//#include <EX_Alarm.h> //Implements Executor (EX)as an Alarm Siren capability via a digital output to a relay
#include <S_TimedRelay.h> //Implements a Sensor to control a digital output pin with timing capabilities

//*************************************************************************************************
//NodeMCU v1.0 ESP8266-12e Pin Definitions (makes it much easier as these match the board markings)
//*************************************************************************************************
//#define LED_BUILTIN 16
//#define BUILTIN_LED 16
//
//#define D0 16  //no internal pullup resistor
//#define D1  5
//#define D2  4
//#define D3  0  //must not be pulled low during power on/reset, toggles value during boot
//#define D4  2  //must not be pulled low during power on/reset, toggles value during boot
//#define D5 14
//#define D6 12
//#define D7 13
//#define D8 15  //must not be pulled high during power on/reset

//******************************************************************************************
//Define which Arduino Pins will be used for each device
//******************************************************************************************

#define PIN_TIMEDRELAY_1 D5 // Starts MDX
#define PIN_TIMEDRELAY_2 D6 // Starts Van
#define PIN_TIMEDRELAY_3 D6 // Unlocks Van

//******************************************************************************************
//ESP8266 WiFi Information
//******************************************************************************************
String str_ssid     = "xxxxx";                           //  <---You must edit this line!
String str_password = "xxxxxx";                   //  <---You must edit this line!
IPAddress ip(10, 0, 2, 69);       //Device IP Address       //  <---You must edit this line!
IPAddress gateway(10, 0, 0, 1);    //Router gateway          //  <---You must edit this line!
IPAddress subnet(255, 255, 0, 0);   //LAN subnet mask         //  <---You must edit this line!
IPAddress dnsserver(10, 0, 0, 1);  //DNS server              //  <---You must edit this line!
const unsigned int serverPort = 8090; // port to run the http server on

// Smartthings / Hubitat Hub TCP/IP Address
IPAddress hubIp(10, 0, 2, 38);    // smartthings/hubitat hub ip //  <---You must edit this line!

// SmartThings / Hubitat Hub TCP/IP Address: UNCOMMENT line that corresponds to your hub, COMMENT the other
//const unsigned int hubPort = 39500;   // smartthings hub port
const unsigned int hubPort = 39501;   // hubitat hub port

//******************************************************************************************
//st::Everything::callOnMsgSend() optional callback routine.  This is a sniffer to monitor 
//    data being sent to ST.  This allows a user to act on data changes locally within the 
//    Arduino sktech.
//******************************************************************************************
void callback(const String &msg)
{
//  Serial.print(F("ST_Anything Callback: Sniffed data = "));
//  Serial.println(msg);
  
  //TODO:  Add local logic here to take action when a device's value/state is changed
  
  //Masquerade as the ThingShield to send data to the Arduino, as if from the ST Cloud (uncomment and edit following line)
  //st::receiveSmartString("Put your command here!");  //use same strings that the Device Handler would send
}

//******************************************************************************************
//Arduino Setup() routine
//******************************************************************************************
void setup()
{
  //******************************************************************************************
  //Declare each Device that is attached to the Arduino
  //  Notes: - For each device, there is typically a corresponding "tile" defined in your 
  //           SmartThings Device Hanlder Groovy code, except when using new COMPOSITE Device Handler
  //         - For details on each device's constructor arguments below, please refer to the 
  //           corresponding header (.h) and program (.cpp) files.
  //         - The name assigned to each device (1st argument below) must match the Groovy
  //           Device Handler names.  (Note: "temphumid" below is the exception to this rule
  //           as the DHT sensors produce both "temperature" and "humidity".  Data from that
  //           particular sensor is sent to the ST Hub in two separate updates, one for 
  //           "temperature" and one for "humidity")
  //         - The new Composite Device Handler is comprised of a Parent DH and various Child
  //           DH's.  The names used below MUST not be changed for the Automatic Creation of
  //           child devices to work properly.  Simply increment the number by +1 for each duplicate
  //           device (e.g. contact1, contact2, contact3, etc...)  You can rename the Child Devices
  //           to match your specific use case in the ST Phone Application.
  //******************************************************************************************
  //Polling Sensors
  
  //Special sensors/executors (uses portions of both polling and executor classes)
static st::S_TimedRelay sensor1(F(“relaySwitch1”), PIN_TIMEDRELAY_1, LOW, true, 1000, 1000, 2);
static st::S_TimedRelay sensor2(F(“relaySwitch2”), PIN_TIMEDRELAY_2, LOW, true, 1000, 1000, 2);
static st::S_TimedRelay sensor3(F(“relaySwitch3”), PIN_TIMEDRELAY_3, LOW, true, 1500, 1);

  //*****************************************************************************
  //  Configure debug print output from each main class 
  //  -Note: Set these to "false" if using Hardware Serial on pins 0 & 1
  //         to prevent communication conflicts with the ST Shield communications
  //*****************************************************************************
  st::Everything::debug=true;
  st::Executor::debug=true;
  st::Device::debug=true;
  st::PollingSensor::debug=true;
  st::InterruptSensor::debug=true;

  //*****************************************************************************
  //Initialize the "Everything" Class
  //*****************************************************************************

  //Initialize the optional local callback routine (safe to comment out if not desired)
  st::Everything::callOnMsgSend = callback;
  
  //Create the SmartThings ESP8266WiFi Communications Object
//STATIC IP Assignment - Recommended
st::Everything::SmartThing = new st::SmartThingsESP8266WiFi(str_ssid, str_password, ip, gateway, subnet, dnsserver, serverPort, hubIp, hubPort, st::receiveSmartString);

//DHCP IP Assigment - Must set your router's DHCP server to provice a static IP address for this device's MAC address
//st::Everything::SmartThing = new st::SmartThingsESP8266WiFi(str_ssid, str_password, serverPort, hubIp, hubPort, st::receiveSmartString);

  //Run the Everything class' init() routine which establishes WiFi communications with SmartThings Hub
st::Everything::init();
  
  //*****************************************************************************
  //Add each sensor to the "Everything" Class
  //*****************************************************************************
st::Everything::addSensor(&sensor1);
st::Everything::addSensor(&sensor2);
st::Everything::addSensor(&sensor3);
  
  //*****************************************************************************
  //Add each executor to the "Everything" Class
  //*****************************************************************************

  //*****************************************************************************
  //Initialize each of the devices which were added to the Everything Class
  //*****************************************************************************
  st::Everything::initDevices();
  
}

//******************************************************************************************
//Arduino Loop() routine
//******************************************************************************************
void loop()
{
  //*****************************************************************************
  //Execute the Everything run method which takes care of "Everything"
  //*****************************************************************************
  st::Everything::run();
}

This is a troubling looking string... :wink:

Be careful with the double quotes. The ones in your sketch don't look quite right to me. In the Arduino IDE, remove and replace each double quote, save, and rebuild the code. Some text editors mess those up to make them look pretty. The C compiler prefers bland and boring.

The first two should look like

static st::S_TimedRelay sensor1(F("relaySwitch1"), PIN_TIMEDRELAY_1, LOW, true, 1000, 1000, 2);
static st::S_TimedRelay sensor2(F("relaySwitch2"), PIN_TIMEDRELAY_2, LOW, true, 1000, 1000, 2);

And your 3rd should look like

static st::S_TimedRelay sensor3(F("relaySwitch3"), PIN_TIMEDRELAY_3, LOW, true, 1500, 0, 1);

Wow I didn't see that. What do you know...it worked!

1 Like

I have now officially moved the last of my ST devices over to HE. After I get the RM rules to run I will be shutting down ST. Woot!

3 Likes

To clarify Dan, the IS_motion reports as Active for 30 seconds, correct? If I wanted to swap that and have it report INACTIVE for those 30 seconds, I would swap active for inactive in this part of the IS_Motion.cpp, correct?

	void IS_Motion::runInterrupt()
	{
		//add the "active" event to the buffer to be queued for transfer to the ST Shield
		Everything::sendSmartString(getName() + F(" active"));
	}

The reason I ask is that when there's a power "hiccup" any lights I have tied to the motion sensors turn on since it reports as active. I take care of that through my power failure recovery automations, but it would be a lot easier if I could just swap it in the boards code. I hesitated changing it before because I didn't want to break anything else.

Ryan,

I am a little confused at exactly what you're trying to accomplish. There is a 30 second timer when the board first powers on, to allow the motion sensor to calm down after being powered on. During this time, I do not believe anything is sent to the hub. Once the initial 30 seconds is up, the GPIO pin is evaluated and the IS_Motion class sends either 'active' or 'inactive' depending on how you've declared the device in your sketch.

Here is the documentation for the IS_Motion device. As you can see, the thrid argument can be used to invert the logic if needed.

//			  Create an instance of this class in your sketch's global variable section
//			  For Example:  st::IS_Motion sensor5(F("motion1"), PIN_MOTION, HIGH, false, 500);
//
//			  st::IS_Motion() constructor requires the following arguments
//				- String &name - REQUIRED - the name of the object - must match the Groovy ST_Anything DeviceType tile name
//				- byte pin - REQUIRED - the Arduino Pin to be used as a digital output
//				- bool iState - OPTIONAL - LOW or HIGH - determines which value indicates the interrupt is true
//				- bool internalPullup - OPTIONAL - true == INTERNAL_PULLUP
//				- long numReqCounts - OPTIONAL - number of counts before changing state of input (prevent false alarms)

The IS_Motion device will report status updates to the hub as fast as the digital input changes. There is no logic to hold the signal 'active' or 'inactive' for 30 seconds. The 30 second logic is only true during power up.

If you can explain what you're seeing, we can take a look to see if there is a potential workaround. Also, what type of motion detector are you using?

As soon as I power on the board motion goes active. No matter whether there is motion or not. I'm asking if whether during power-up, can it be set to NOT send active.

The sensor works 100% perfect the rest of the time. My question is specifically about powerup. Sorry if that wasn't clear.

Maybe you didn't notice, but this was in response to a specific post a few back asking about the 30 second boot-up (or powerup). I thought I clicked respond to that one so they would link.

I am seeing that it reports active as soon as power is applied to the board, whether a sensor is connected to the pin and whether I have HIGH or LOW in the constructor.

Ryan,

So to run a test, I just pulled out a spare NodeMCU ESP8266 board, loaded the ST_Anything_Multiples_ESP8266WiFi.ino sketch on it and created a Parent Device on my Hubitat Hub. I have RESET the board, and POWER CYCLED the board, numerous times. In every case, the IS_Motion device does NOT report any data to Hubitat until the 30 seconds are up, and then it always reports the correct status of the GPIO pin (in my case 'active' for HIGH, and 'inactive' for LOW.)

If you'd like, I can review your sketch to see if I can figure out what is going on. Just remove your WiFi credentials and post it here and I'll gladly take a look.

Here's my serial monitor from the Arduino IDE at bootup:

SmartThingsESP8266WiFI: Intialized

Disabling ESP8266 WiFi Access Point

ArduinoOTA Ready


Everything: init ended
Everything: Free RAM = 44304
Everything: adding sensor named motion1
Everything: Free RAM = 44304
Everything: adding sensor named motion2
Everything: Free RAM = 44304
Everything: adding sensor named contact1
Everything: Free RAM = 44304
Everything: adding executor named switch1
Everything: Free RAM = 44304
Everything: initDevices started
Everything: Free RAM = 44304
IS_Motion: 30 second Motion Sensor Calibration Started...
IS_Motion: 30 second Motion Sensor Calibration Started...
Everything: Sending: switch1 off
Everything: initDevices ended
Everything: Free RAM = 44408
Everything: Sending: contact1 open
IS_Motion: Motion Sensor Calibration Finished
IS_Motion: Motion Sensor Calibration Finished
Everything: Sending: motion1 active
Everything: Sending: motion2 active
Everything: Sending: motion2 inactive
Everything: Sending: motion1 inactive
Everything: Free Ram = 44408

This is with no sensors even hooked up. And when I hook them up and reboot the board, when I can't have the monitor hooked up, the lights that repsond to those two motion sensors turn on.

// SmartThings Library for ESP8266WiFi
//******************************************************************************************
#include <SmartThingsESP8266WiFi.h>

//******************************************************************************************
// ST_Anything Library 
//******************************************************************************************
#include <Constants.h>       //Constants.h is designed to be modified by the end user to adjust behavior of the ST_Anything library
#include <Device.h>          //Generic Device Class, inherited by Sensor and Executor classes
#include <Sensor.h>          //Generic Sensor Class, typically provides data to ST Cloud (e.g. Temperature, Motion, etc...)
#include <Executor.h>        //Generic Executor Class, typically receives data from ST Cloud (e.g. Switch)
#include <InterruptSensor.h> //Generic Interrupt "Sensor" Class, waits for change of state on digital input 
//#include <PollingSensor.h>   //Generic Polling "Sensor" Class, polls Arduino pins periodically
#include <Everything.h>      //Master Brain of ST_Anything library that ties everything together and performs ST Shield communications

//#include <PS_Illuminance.h>  //Implements a Polling Sensor (PS) to measure light levels via a photo resistor on an analog input pin 
//#include <PS_Voltage.h>      //Implements a Polling Sensor (PS) to measure voltage on an analog input pin 
//#include <PS_TemperatureHumidity.h>  //Implements a Polling Sensor (PS) to measure Temperature and Humidity via DHT library
//#include <PS_Water.h>        //Implements a Polling Sensor (PS) to measure presence of water (i.e. leak detector) on an analog input pin 
#include <IS_Motion.h>       //Implements an Interrupt Sensor (IS) to detect motion via a PIR sensor on a digital input pin
#include <IS_Contact.h>      //Implements an Interrupt Sensor (IS) to monitor the status of a digital input pin
//#include <IS_Smoke.h>        //Implements an Interrupt Sensor (IS) to monitor the status of a digital input pin
//#include <IS_CarbonMonoxide.h> //Implements an Interrupt Sensor (IS) to monitor the status of a digital input pin
//#include <IS_DoorControl.h>  //Implements an Interrupt Sensor (IS) and Executor to monitor the status of a digital input pin and control a digital output pin
//#include <IS_Button.h>       //Implements an Interrupt Sensor (IS) to monitor the status of a digital input pin for button presses
#include <EX_Switch.h>       //Implements an Executor (EX) via a digital output to a relay
//#include <EX_Alarm.h>        //Implements Executor (EX)as an Alarm capability with Siren and Strobe via digital outputs to relays
//#include <S_TimedRelay.h>    //Implements a Sensor to control a digital output pin with timing/cycle repeat capabilities

//*************************************************************************************************
//NodeMCU v1.0 ESP8266-12e Pin Definitions (makes it much easier as these match the board markings)
//*************************************************************************************************
#define LED_BUILTIN 16
#define BUILTIN_LED 16

#define D0 16  //no internal pullup resistor
#define D1  5
#define D2  4
#define D3  0  //must not be pulled low during power on/reset, toggles value during boot
#define D4  2  //must not be pulled low during power on/reset, toggles value during boot
#define D5 14
#define D6 12
#define D7 13
#define D8 15  //must not be pulled high during power on/reset

//******************************************************************************************
//Define which Arduino Pins will be used for each device
//******************************************************************************************

#define PIN_MOTION_1              D5
#define PIN_MOTION_2              D6
#define PIN_CONTACT_1             D1
#define PIN_SWITCH_1              D2


//******************************************************************************************
//ESP8266 WiFi Information
//******************************************************************************************
String str_ssid     = "Caslerville";                           //  <---You must edit this line!
String str_password = "toomanysecrets";                   //  <---You must edit this line!
IPAddress ip(192, 168, 1, 108);       //Device IP Address       //  <---You must edit this line!
IPAddress gateway(192, 168, 1, 1);    //Router gateway          //  <---You must edit this line!
IPAddress subnet(255, 255, 255, 0);   //LAN subnet mask         //  <---You must edit this line!
IPAddress dnsserver(192, 168, 1, 1);  //DNS server              //  <---You must edit this line!
const unsigned int serverPort = 8090; // port to run the http server on

// Smartthings / Hubitat Hub TCP/IP Address
IPAddress hubIp(192, 168, 1, 12);    // smartthings/hubitat hub ip //  <---You must edit this line!

// SmartThings / Hubitat Hub TCP/IP Address: UNCOMMENT line that corresponds to your hub, COMMENT the other
//const unsigned int hubPort = 39500;   // smartthings hub port
const unsigned int hubPort = 39501;   // hubitat hub port

//******************************************************************************************
//st::Everything::callOnMsgSend() optional callback routine.  This is a sniffer to monitor 
//    data being sent to ST.  This allows a user to act on data changes locally within the 
//    Arduino sktech.
//******************************************************************************************
void callback(const String &msg)
{
//Serial.print(F("ST_Anything Callback: Sniffed data = "));
//Serial.println(msg);
//if (msg == "contact1 open") {st::receiveSmartString("switch1 on");}
//if (msg == "contact1 closed") {st::receiveSmartString("switch1 off");}
}

//******************************************************************************************
//Arduino Setup() routine
//******************************************************************************************
void setup()
{
  //******************************************************************************************
  //Declare each Device that is attached to the Arduino
  //  Notes: - For each device, there is typically a corresponding "tile" defined in your 
  //           SmartThings Device Hanlder Groovy code, except when using new COMPOSITE Device Handler
  //         - For details on each device's constructor arguments below, please refer to the 
  //           corresponding header (.h) and program (.cpp) files.
  //         - The name assigned to each device (1st argument below) must match the Groovy
  //           Device Handler names.  (Note: "temphumid" below is the exception to this rule
  //           as the DHT sensors produce both "temperature" and "humidity".  Data from that
  //           particular sensor is sent to the ST Hub in two separate updates, one for 
  //           "temperature" and one for "humidity")
  //         - The new Composite Device Handler is comprised of a Parent DH and various Child
  //           DH's.  The names used below MUST not be changed for the Automatic Creation of
  //           child devices to work properly.  Simply increment the number by +1 for each duplicate
  //           device (e.g. contact1, contact2, contact3, etc...)  You can rename the Child Devices
  //           to match your specific use case in the ST Phone Application.
  //******************************************************************************************
  //Polling Sensors
    
  //Interrupt Sensors 
  static st::IS_Motion              sensor1(F("motion1"), PIN_MOTION_1, HIGH, false, 500);
  static st::IS_Motion              sensor2(F("motion2"), PIN_MOTION_2, HIGH, false, 500);
  static st::IS_Contact             sensor3(F("contact1"), PIN_CONTACT_1, LOW, true, 1000);  
  //Executors
  static st::EX_Switch               executor1(F("switch1"), PIN_SWITCH_1, LOW, false);
  
  //*****************************************************************************
  //  Configure debug print output from each main class 
  //  -Note: Set these to "false" if using Hardware Serial on pins 0 & 1
  //         to prevent communication conflicts with the ST Shield communications
  //*****************************************************************************
  st::Everything::debug=true;
  st::Executor::debug=true;
  st::Device::debug=true;
//  st::PollingSensor::debug=true;
  st::InterruptSensor::debug=true;

  //*****************************************************************************
  //Initialize the "Everything" Class
  //*****************************************************************************

  //Initialize the optional local callback routine (safe to comment out if not desired)
  st::Everything::callOnMsgSend = callback;
  
  //Create the SmartThings ESP8266WiFi Communications Object
    //STATIC IP Assignment - Recommended
    st::Everything::SmartThing = new st::SmartThingsESP8266WiFi(str_ssid, str_password, ip, gateway, subnet, dnsserver, serverPort, hubIp, hubPort, st::receiveSmartString);
 
    //DHCP IP Assigment - Must set your router's DHCP server to provice a static IP address for this device's MAC address
    //st::Everything::SmartThing = new st::SmartThingsESP8266WiFi(str_ssid, str_password, serverPort, hubIp, hubPort, st::receiveSmartString);

  //Run the Everything class' init() routine which establishes WiFi communications with SmartThings Hub
  st::Everything::init();
    
  //*****************************************************************************
  //Add each sensor to the "Everything" Class
  //*****************************************************************************
  st::Everything::addSensor(&sensor1);
  st::Everything::addSensor(&sensor2);
  st::Everything::addSensor(&sensor3);

       
  //*****************************************************************************
  //Add each executor to the "Everything" Class
  //*****************************************************************************
  st::Everything::addExecutor(&executor1);
    
  //*****************************************************************************
  //Initialize each of the devices which were added to the Everything Class
  //*****************************************************************************
  st::Everything::initDevices();
  
}

//******************************************************************************************
//Arduino Loop() routine
//******************************************************************************************
void loop()
{
  //*****************************************************************************
  //Execute the Everything run method which takes care of "Everything"
  //*****************************************************************************
  st::Everything::run();
}

And there's my sketch.

And this is the log from Hubitat when I just did the exact same thing you just did:

[dev:183] 2018-10-26 23:10:47.762 debug parse(motion active) called

How are your sensors wired? For a HIGH interupt or LOW? Could it be because the pin is floating for that period of time? The sensors I have are HIGH so I can't use the internal pull-up, cause it will always read active, right? The sensors are simple HC-SR501's.

They output 3.3v on active.

Those are the same type of PIR Motion sensors that I have used previously for testing. Having Internal Pullup disabled for those makes sense, as they drive the signal either High or Low (no floating signal). It is important that jumper(s) on those devices are set correctly. ST_Anything expects a continuous HIGH or LOW to be emitted for ACTIVE or INACTIVE, repsectively. We do not want a pulse-train when active.

So, when testing on the workbench, make sure you tie the GPIO pin for both of these IS_Motion devices to GND while booting up and running, and the board should report 'inactive' for both devices. Then tie them to 3.3v, and the board should report 'active' for both devices. This is the exact test I ran earlier.

Floating signals are almost always bad. Thus, the need for the Internal Pullup on the magnetic contact sensors, which are simple dry contact magnetic reed switches. The internal pullup keeps these pins at 3.3v, until the switch is closed, which shorts the pin safely to GND. Thus we get the two states, even though the switch cannot drive the signal high.

If you still see the Active/Inactive happening on the workbench, with both pins pulled low to GND during startup, I would have to suspect that your copies of IS_Motion.h/.cpp have been modified in some way. Maybe try grabbing a fresh copy from GitHub?

BTW - I have never had one of those super inexpensive HC--SR501 PIR motion sensors last reliably for more than about a month before locking up. I now use this motion detector with HubDuino. It requires external power, and has a dry contact output, thus requiring the use of Internal Pullup. Since switching to this, I have had zero false activations.

2 Likes

BTW...once you said you weren't seeing it, I had to post it to prove I wasn't crazy. :stuck_out_tongue_winking_eye: :clown_face:

So, here's the really crazy part...I tied just D5 to gnd to test it out. Thinking that motion 2 would go active and motion 1 wouldn't. But this time, neither of them went active. :open_mouth:

I think that proves that the sensors are leaving the pin floating a little longer than my board is expecting. Or maybe it's cause I have a longer line running from the sensors to the board. In either case, I've already adjusted for it in my "recovering from power loss" piston (yes, I know it's a dirty word but I like variables) so it's not a big deal. I was just wondering if there was an easier way to address it, that's all. They work perfect almost 100% of the time besides that. Oh, and since moving to Hubitat the response time on them is about 1/5 what it was with ST. Local rules! LOL Thanks.

Edit: I've had 5 of them all over my house for over a year without a problem.

The 30 second wait on startup should provide plenty of time for the sensor to output a signal before ST_Anything sends anything to your Hubitat hub... You could increase this to see if you're somehow on the hairy edge, timing-wise. Just modify the 30000 in the IS_Motion.cpp to something larger, like 60000 ms.

I'll give that a shot....thanks. And yeah, those sensors look a lot better but these are all just for lighting, not security. If they lock up, i've got 3 or 4 of them left from the batch that I bought. For $2 each, how can you go wrong? First floor ones for security/lights are wireless.

BTW, I tried it out with 60000 too and they still went active on me. No sweat. Thanks for trying! :slight_smile:

1 Like

Sorry to bug you...but I had a question about the servo library. I'm trying to switch over from using my pieced together blinds sketch to using the servo capability but I'm not finding a good way to adjust them other than going into Hubitat and entering the set level number manually or using a slider on a dashboard. Preferably I would want to move them in one direction while one button was held and in the other direction when another button was held, I tried to add the Level Change capability to the servo child driver but that very quickly proved to be WAY beyond my capabilities. :wink:

BTW, both buttons are on the same board, so I could do this with a callback also. Any tips? I was going to use standard Arduino button language but I couldn't really decipher where the servo level is stored (what constant or variable) to be able to adjust it with the button press. Any advice you have would be appreciated. If you could help me figure that out, I think I could start to work on something.

Hi Ryan. Sorry for the slow response. The Servo support is currently minimal, at best (as you have figured out.) I added it for a ST user who insisted he was going to DIY his own smart air vents. I literally implemented the simplest solution I could that met his requirements.

In the process, I realized that proper servo library support would be very difficult to implement in the current architecture of ST_Anything. I have never spent the time to wrap my head fully around what it would take to handle these properly, in a manner than prevents making blocking calls which messes up the network communications. This is the same issue that is faced for the Neopixel LED strips.

I wish I had better news, but at this time, I just don't have the time or energy to focus on what might amount to an overhaul of ST_Anything. It might be better to focus energy on OmniThing as my son has already taken into account many of the design limitations of ST_Anything when he designed OmniThing.

Any idea if Daniel plans on implementing servo capability anytime soon? Thanks.

He supports Servo capability already in OmniThing. I am just not sure what he has will accomodate your requirements. You'll need to ask him directly.