[DEPRECATED] ST_Anything - Arduino/ESP8266/ESP32

[daz808]

@ogiewon Thanks for the reply Dan, I had a look at the setup as you suggested and everything seemed as expected, so I then went into the parent setup on the ST app thinking a remove and re-install might be a good idea, and I noticed that I had typed the ip address wrong - instead of 192.168.1.119 I had 192.169.1.119, so I corrected it and it started working right away, woohoo!

Really strange why some parts of it were working with the wrong ip address though huh? Total noob mistake on my part, but hopefully my embarrassment might help others if they experience similar problems

Thanks again

[daz808]

One more question @ogiewon in the Multiples parent there is the option to configure buttons I take it that if using the sketch as default I just leave that at 0?

[ogiewon]

Correct. If not using any “Button” devices, leave the value at zero.

[Carbonatom13]

The motion sensor I have is a honeywell 4-wire sensor, don’t have the specific model currently. I have it wired into pin 44 and the ground, but maybe i’m not quite understanding how the “motion sensor” code works.

How can i bench test the arduino without the sensor? I tried jumping 44 to ground, but that didn’t do anything

[ogiewon]

Ahhhh!!! You may have hit the nail on the head with your last comment!

Motion Detectors for Arduino’s come in two flavors… Active HIGH and Active LOW. This behavior is user selectable when creating the IS_Motion device in your Arduino sketch’s setup() routine.

In the ST_Anything_Multiples_EthernetW5100.ino example sketch you will find the following line of code defining the first motion detector device:

  //Interrupt Sensors 
  static st::IS_Motion              sensor9(F("motion1"), PIN_MOTION_1, HIGH, false, 500);

If you read the comment at the top of the IS_Motion.h or .cpp file you will find the instructions that explain each of the arguments:

//			  Create an instance of this class in your sketch's global variable section
//			  For Example:  st::IS_Motion sensor5("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)

So, the default example expects a HIGH voltage (5V for Arduino MEGA) to be applied to the pin to activate the motion device. Since your motion detector is most likely a simple set of dry contacts, this will not work for your old alarm system motion detectors. Instead, change your sketch’s code to look similar to the following:

  //Interrupt Sensors 
  static st::IS_Motion              sensor9(F("motion1"), PIN_MOTION_1, LOW, true, 500);

LOW means that applying GND to the input pin will trigger the device to be active.

true means to use the Arduino’s Internal PullUp resistor which will supply 5V on the digital input pin.

This combination should have the same result as all of the contact sensors. That is, by simply jumpering GND on the Arduino to the digital pin for the motion detector, you should see motion device in SmartThings change from “inactive” to “active”.

[Steph]

Hi Dan
A while ago you told me how to change to celcius for all my sensor at once.

Since I made the last update everything went back to fahrenheit, I when back to the parent_st-anything_ethernet, remove the / in front of the line and did not work, any idea.

            if (namebase == "temperature") {
            	double tempC = fahrenheitToCelsius(value.toFloat())  //convert from Farenheit to Celsius
               	value = tempC.round(2)
			}

[ogiewon]

Steph,

I’ll take a look at this over the weekend. There have been some changes to the baseline DH code, which will allow the F vs C to configurable for each temp sensor. I just need to add that option to the Child Temperature DH.

Should have a fix in the next day or so.

Dan

[Carbonatom13]

Some success this evening, I got my relay/alarm working (really made the dogs unhappy while I was debugging this).

No so successful on the motion detector

So i made the modification you mentioned above, and now when I jump pin44 to gnd, it shows the sensor as active. Also, when i hook up the motion sensor without a power source it shows active (until i unhook the ground). This makes sense I think because the wiring is NC normally closed i think? I feel like I am very close, but just can’t get this thing completely figured out.

I pulled the model/installation manual for my honeywell sensor (IS2535 for reference) and looked at the wiring. I currently have pin44 wired to the NC terminal and gnd wired to the C terminal on the motion sensor. I’m supplying power from my old battery backup (temp while i troubleshoot). When I walk in front of the motion sensor, its indicator LED lights up, but the state does not change on the ST app.

Thoughts?

Thanks in advance for the help.

[ogiewon]

If your Motion Detectors are Normally Closed (i.e. a short circuit when there is no motion), then we need to make another minor tweak to the IS_Motion’s configuration as shown below.

  //Interrupt Sensors 
  static st::IS_Motion              sensor9(F("motion1"), PIN_MOTION_1, HIGH, true, 500);

By setting the 3rd argument to HIGH, the digital input will “see” 5V on the input pin as a active motion input. This will only happen when the motion detector circuit goes from closed (i.e. short circuit) to open. The Internal Pullup (4th argument) will cause 5V to appear on the pin, and this will be seen as an active input (i.e. motion active).

Again, please verify the output pins of the motion detector by connecting them to a multimeter set on RESISTANCE measurement (Note: Always verify there is no voltage (AC or DC) across the motion detectors output pins, in both the active and inactive states, before checking for continuity.)

I just looked up your particular model of motion detector. Please make sure there is no EOL (end of line) resistor installed on the back of the actual device. If there is, please try removing it to see if everything starts working as expected. The EOL resistors are only needed for the old alarm panels. There are there to help detect tampering with the wiring, IIRC.

[ogiewon]

@Steph

I have uploaded a new version of the “Child Temperature Sensor” Device Handler to the ST_Anything Github repository. This version allows you to select one of three options for unit conversion…

1. None
2. Fahrenheit to Celsius
3. Celsius to Fahrenheit

This should provide you with all of the flexibility needed to adjust the units as necessary without having to change the Arduino code.

You will need to go into the Settings for each Temperature Child Device and select the correct conversion type.

Please reply back to this post to let me know how your testing goes.

Dan

[John_N]

@ogiewon, thank you for your work on this. I wasn’t a SmartThings user prior to this, nor Arduino, nor developer, …more a tinkerer. I decided to give this a shot and I’ve finally run into a problem I could use your advice on.

I started with 1 NodeMCU, wired up a few inputs and got the system working. Occasionally, I’d have a false alarm on a door where the sensor isn’t installed well and when the door moves, it would of course trigger. I’m going to work on this.

I added another NodeMCU for additional IO and this is when the problems started. I’m now getting fast transitions that look like false alarms on wired sensors all over the house at random times and with different types of sensors…contact and glassbreak that I’ve defined as contact sensors. It seems like it’s affecting the first board even though I didn’t have this problem previously. The additional board has triggered something.

The transitions always show up as closed/open/closed transitions. I can’t see how fast they are as the SmartThings interface doesn’t seem to register seconds.

What do you think is happening here? Would it make sense to add debounce code somewhere?

[ogiewon]

@John_N, glad you’re enjoying the “tinkering” with ST and microcontrollers. I would need to see a wiring diagram of what you have currently to help debug what sounds very much like an electrical issue to me. Have you added anything to your sketch’s loop() routine by any chance? Make sure you never add any delay() or large looping statements as those will mess up the WiFi communications.

As for debounce, the IS_Contact sensor device already has a debounce capability. Take a look at the top of the IS_Contact.h or .cpp file for details… I have copied the pertinent section below. Just make sure you have the debounce count parameter defined when you create the IS_Contact devices in your sketch’s setup() routine. 500 is just a guess, and seems to not delay the notification very much, and addresses typical debounce issues. Feel free to increase it if desired. Note, this count refers to the number of times through the sketch’s loop() routine that must be executed after the input pin sees a change (and stay in the new state) before notifying SmartThings. Set it too high, and you will have delays and could miss true open/close events.

//			  Create an instance of this class in your sketch's global variable section
//			  For Example:  st::IS_Contact sensor6("contact1", PIN_CONTACT, HIGH, true, 500);
//
//			  st::IS_Contact() 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 input
//				- bool iState - REQUIRED - 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)

[John_N]

I haven’t added code anywhere but modifying the appropriate sections for the pins in the Arduino IDE.

As for the circuit design, each input to the NodeMCU has the 3.3V ucontroller source through a pull up resistor of 3.3kohms. All inputs are active high. Nothing else.

Here are photos of the first ucontroller. The 2nd is wired similarly.

[John_N]

[ogiewon]

OK, we may be on to something… Are you using an external 3.3v power supply? If so, it is probably conflicting with the NodeMCU’s 3.3v onboard power source.

The standard examples are coded to use the INTERNAL PULLUP resistor of the Arduino/NodeMCU. This provides 3.3v on each digital input pin. So, all you need to do is connect the pin to your contact sensor, and then connect the other wire from the contact sensor to the GND on the NodeMCU board. That’s it! No external power supply needed for the input pins.

For your breadboard testing, just use a jumper wire from GND to the pin and you will see the state changes in SmartThings.

Hopefully this helps to clear up the random events.

[John_N]

An update…
I’m not supplying a 3.3V supply - it’s coming from the 3.3V pin on the NodeMCU. I’ve determined the pins do not have 3.3V on them and they only register the input change when I supply an external supply. Without this, it doesn’t work at all.

Over the last 12 hours, I’ve had 3 false events, 2 are from the front door and another is a patio door. In all 3 cases, the length of the event is ~20ms.

With 500 code cycles to confirm @80MHz, this is 6.25uS, if my math is right. I’m thinking of changing the 500 to 2.4e6!

[ogiewon]

Please post your sketch here (use the preformatted text button when doing so) so I can take a look.

[flyerdp (David P.)]

I have a bit of a conundrum here. I have 5 Temp Humidity sensors and 7 motion sensors attached to an arduino Mega running ST Anythign communicating to ST via a Thingshield.

I use the humidity sensors to trigger vent fans while showering in my bathrooms, one for inside ‘normal’ and one for outside readings. Last week the fans stopped coming on when I was in the shower so I checked and I was not getting updates to my readings looking at the phone app. The day before while at work I was looking at another smartapps and saw there was an update to the temp sensor fo this project (which I have since read had to do with Temp scale addition). I went ahead and updated it. So my thinking at the time was that I must have had to have a corresponding update to the arduino’s code to make this new version of the smart-app work so I re-downloaded the st_anything adruino project from github and unpacked it in my arduino libraries folder. I compiled my project and uploaded. Still no readings. I end up taking the housing off the arduino _ thingshield and see that the red light is lit in the middle of the thingshield. I reset a few times and end up re-pairing to the hub. I guess that LED means something is wrong? Don’t recall.

Voila… temp/humidity updates etc… I thought all was well but a few minutes go by and I hear vent fans coming on. I look at my readings for the sensors on my phone and see either -1% for 1 sensor and/or 3308.1% for a couple of other ones. At least 3 of the 5 look normal. After this (for a few days) I very rarely I see normal readings across the board. I hook up the USB cable to the mega again after a few days and watch debug and see DHT checksum errors. If I see that error the value is usually -1 sometimes 3308.1%.

Thoroughly confused on how what I at first thought was a code issue, in the end was just the thingshield was “hung” or something has turned in to these erroneous readings?! I moved no hardware, disconnected no wires save the USB and power.

The wire runs are sub 25 feet for most of the sensors but two are 60ish feet. Those 2 yield the most errors. I move to a junction point for the wires between one floor and another and I cut one of the 2 long wires and hook in to the signal and ground to a mega right there running the same code from my laptop and watch debug again. Readings look great for 10 minutes. First time I have seen that in days. I re-attach the other end of the wire that I cut off that is still hooked in upstairs and immediately readings go -1 or 3308%. So now I am thinking wire length. I read the AM2301 spec and through broken English they talk about a 30 M signal cable and what I believe they say is if its less than 30 M you need to use a 5.1K ohm resistor “accordingly”. My assumption is this means resistance depends on length. At any rate I try a few resistors and no change. In fact I get no readings just -1 when I use anything from 1k to 5.1k in-line with the signal wire at the end of the wire attached to the mega.

I walk away again with no positive results other than I pulled nearly 10 extra feet out of that wire and get intermittent good readings now. I modify my core rules to say if the readings is over 100% or below 1% then ignore it so my fans don’t change based on bad readings.

I re-visit this last night and note that the ST_Anything project came with its own DHT Library when I re-downloaded it. I had one in my libraries already called DHTLib that I got when I first received the sensors to test them with a good few months before buying more and employing them for this project. I delete the DHT that came with ST_Anything and recompile with warnings about the class saying it works but you are programming via avr or something (sorry this is after the fact and not in front of me) further is says that it should work.

I go ahead and upload that and boom. No more erroneous readings. I thought perhaps this older class masks bad readings by just ignoring them and not reporting them? It has been running for 12 hours now and I have readings nearly ever second that while sometimes are identical are usually different by anywhere from .1 to .5 % between minutes it reads so that doesnt seem to be the case.

So this was the long way around to ask… is anyone else using AM2301/DHT21 sensors? how long are your cable runs? Are you seeing anything like I was with bad readings? I am relieved this is working but puzzled at the cause/solution? I would not have thought that a later version of the DHT class would be the culprit in this!

Anyone have any thoughts on this? Oh and sorry for the book…

[vseven (Allan)]

So this might be partially my fault. I asked Dan to update the DTH libraries because the old ones he was using (0.1.13) were causing weird time out issues on the ESP32 so he did update them to the latest “stable” version available. Whats weird is it really shouldn’t have caused any issues, the stable library is for universal compatibility with sensors and controllers. It can be found here: https://github.com/RobTillaart/Arduino/tree/master/libraries/DHTstable

For me the updated libraries helped, at least on my DTH22. If you need you can still get the old 0.1.13 and see if that makes a difference: https://github.com/RobTillaart/Arduino/tree/e2d0b3b61327c64601800f290f99447b646bda7b/libraries/DHTlib or browse what changed with the 0.1.* versions: https://github.com/RobTillaart/Arduino/tree/master/libraries/DHTlib but even on that page it says you should use the “stable” version for the most compatibility.

For the record my wire run was less then 3 feet and I was having time out issues on the ESP32. With the newer “0.2.1 Stable” library it rarely happens.

[John_N]

Hi Dan, I added (, false, 2000) to the contact lines and haven’t had any misoperations for the last couple days. I think I’m good now.