Connect wired alarm system sensors to SmartThings with a NodeMCU ESP8266 [deprecated]

Hi @dradprice3, I don’t think I have a siren or strobe in my setup at my house, but I’m sure it probably could be done. To be clear, I’m bypassing the alarm system panel entirely and just using the wiring for the sensors.

What are you doing on end of line resistors?

Um … nothing. I’m not an electrical engineer, I’m a software guy. I don’t know anything about resistors, so I decided to just try plugging in the wires directly to the NodeMCU and see if it works. It does! Maybe this is a grave noob mistake, but so far so good. From what I’ve read the ESP8266 has an “internal pullup resistor” which I am enabling in the code, but I’m not even 100% sure what this means.

The pull-up resistors help to make sure the voltage at the ESP input is in a clear hi or low, 1 or 0, state. Without them, it might possibly “float” somewhere in between hi and low, or bounce around creating open close events unexpectedly.

I’m only seeing one picture if you meant to post more :slight_smile:

I’m only seeing one picture if you meant to post more :slight_smile:

Since I’m a SmartThings community noob, the website only let me post one picture. There are a couple more on my Github project (linked above).

I’m not entirely sure this is what @dradprice3 meant. End-of-line resistors are often used in alarm systems to make sure that the wiring hasn’t been compromised.

You basically have a resistor in series with a device, which gives the panel itself an indication that the contact is open (no voltage) or “closed and secured” – by taking into account that the resistor in the line reduces the voltage. Without the resistor, you could fool the panel by creating a short in the line after the contact. If the panel doesn’t care about voltage it would just see that the loop is closed and wouldn’t know that the wiring has been compromised.

1 Like

I haven’t figured out your approach here, I’ve been using @Jason_Bush’s example. I don’t see where you create a SmartThings endpoint for the ESP8266 to post to?

With Jason’s there is a DH for the whole ESP which creates difficulties handling multiple contact sensors. With yours you have multiple DH plus a smartapp for each ESP. My preference would be to have one DH because in my head I want to hook as many sensors to each ESP as possible :wink:

I’m more of an EE / embedded software guy :slight_smile: I am not familiar with LUA, I’ve been using Arduino/C on mine.

I think you are right, I was referring specifically to the ESP pullups Nate asked about. I wasn’t familiar with the alarm system end-of-line resistors. I think in order to use end-of-line resistors as you describe, you have to detect 3 states (hi/mid/lo) which can’t be done on a ESP GPIO pint (I don’t think???). You would need an analog input for each contact sensor; ESP only has one.

@kevin The endpoint is created by the SmartApp. See: https://github.com/heythisisnate/nodemcu-smartthings-sensors/blob/master/SmartThings/CloudSensorSmartApp.groovy#L19
There’s documentation on how this works here: http://docs.smartthings.com/en/latest/smartapp-web-services-developers-guide/smartapp.html#mapping-endpoints

If you’re using my Lua code, you’ll just have to edit the variables.lua file and update the apiEndpoint variable to the SmartApp endpoint that you get back after completing OAuth flow as documented here: http://docs.smartthings.com/en/latest/smartapp-web-services-developers-guide/authorization.html#get-smartapp-endpoints

The only reason for multiple device handlers is that I’m using two different types of devices (Motion sensor and contact sensor) and they have different ST capabilities/attributes. If you only have contact sensors, you only need the one device handler to handle as many sensors as you can fit on the ESP.

I wasn’t familiar with Lua before this project either, but it feels a lot like Javascript which I do have 10+ years of experience with. It was surprisingly easy to figure out! I’m sure a similar thing could be written using Arduino too, it’s just not my cup of tea.

I hope this helps. Let me know.

Maybe I mis-spoke a bit, you have to add 3 contact sensor devices that use your one DH. I’m hoping for one device for each ESP, with one DH (which has multiple contact sensors in it). For comparison, like a SmartThings multisensor has several capabilities in it… we don’t have to add a separate device for each capability.

Not knocking your work by any means :slight_smile: It seems like a nice straight forward example! Thanks for sharing!

Gotcha. I think I understand what you’re asking, but I still don’t see how you could have only one device for three different doors that you want to monitor. I understand the example of a multisensor which does have a few different capabilities on the same device, but in this case each device only has one capability (contact sensor). Yes, in my example I set up three different devices, each using the single device handler, so that each door opening/closing can be monitored independently.

I would be interested in purchasing this board with your code already loaded. Can you also provide a write up to modify once received also? I currently have 8 window contact sensors and 3 door sensors. Would the module be able to handle that? Thanks in advance

Yes, I would be interested in purchasing.
Thank you

@jackduffy @Raymond_Lopez @copperz I’m glad there’s interest! At this point I’m not really ready to distribute. Mainly because I can’t think of a good way to securely load your credentials … I’d need your WiFi password, SmartThings OAuth token, and device ids to fully preload the NodeMCU. I think this might be tricky, and you’d probably want to test it out using your computer anyway.

@Raymond_Lopez With a total of 11 sensors, I think you’d need at least 2 NodeMCU boards (maybe three). The board has 13 GPIO pins, but in my experimentation I found that many of them don’t work well or cause strange problems on the device. It took a lot of trial and error, but I found 4 or 5 pins that work consistently. It shouldn’t be a problem at all to have multiple boards all posting to the same SmartApp.

I’m planning on writing up step-by-step setup instructions with a lot more how-to detail in the coming week and packaging up my code for a release. I hope to make it easy enough for even a non-programmer to set up.

Also, I think I solved the sensors out-of-sync problem that I described the other day! I improved my lua code to better handle HTTP timeouts, which I observed occasionally. The latest code is up on my Github: https://github.com/heythisisnate/nodemcu-smartthings-sensors

@heythisisnate Yes, I’ve noticed the same issue.

Edited: I see that you have updated your code. I will try that and let you know how it goes. Thanks again!!

I just added a lot of documentation and a step-by-step how to setup guide on my Github project:

I hope this helps those of you who were intimidated to try it. Post here with any questions/feedback.

1 Like

I got the following error trying to generate the token

Oh No! Something Went Wrong!
Error
500: Internal Server Error
URI
/oauth/authorize
Reference Id
**************************** (No idea if I need to keep that secure)
Date
Tue Feb 07 21:59:33 UTC 2017

edit: Turns out that error is because I’m dumb. I forgot to save the SmartApp after enabling OAuth.

@flyize This looks like an error internal to SmartThings platform. Are you sure that you “published” the SmartApp first before trying the OAuth flow? I saw a similar error once when I forgot to click publish.

Edited my edit so that it’s more obvious. You were correct.

Now I’m having issues with ESPlorer. Mine shows that it’s connected to COM4, but every time I try to upload something, it just shows the word ERROR after each line.

I tried another program and it doesn’t seem to be working either. How do I determine if its my lack of knowledge or a bad board?

Thank you @flyize and @Raymond_Lopez for helping with the details over DM! We’ve found a couple problems, and I just updated the README with more complete instructions.

  1. I left out the step about flashing the NodeMCU firmware. I didn’t originally think this was necessary but apparently it is! Before you can load the lua code, you have to re-flash the device’s firmware.
  2. Since I wrote this code, it looks like the NodeMCU firmware team has released a new major version, 2.0.0, which apparently has some compatibility problems with the HTTP library :cry:. For that reason, I’ve included the exact firmware binary in my repo that I know works.

When I have some time I’ll look into debugging my application on the newer firmware.

I hope this helps anyone who was blocked on this.

2 Likes