Sure, this is a pretty simple attempt… cut out my code from the middle and verify what’s going on in Linux. Once it works there, PHP will work also. Below are the commands used. After changing connection of that pin, re-run the second GPIO GET command and see if the pin status updated as expected. 24 is the pin number below, change it as needed.
sudo gpio -g mode 24 in
sudo raspi-gpio get 24Gave up on ST Devs who broke the Alexa integration. They now query the Temperature capability and expect an integer in that field even though nobody asked for that capability to be monitored. I simply updated the device handler to allow users to choose between Fahrenheit and Celsius in the config of the DTH. I also default a zero in case the sensor is not connected, etc. Grab it on GitHub per the first post.
v1.0.20180130 - Modified logic to be Alexa friendly. Non-integer or null temperature did not work. Now able to select F or C for the temperature reading. Added title to PHP.
Super excited about this project. I’m new to Rpi and this has been an interesting one to start with. I’m struggling with the Open/Close sensors registering on the Index.php page and hoping somebody could help.
I have a newer Rpi 3 and there were a few dependencies that were throwing me for a loop. php5 and php5-gd aren’t available anymore so I installed php7 and php7.0-GD. After I got past that, I was able to get the relays to trigger but the GPIO changes are not triggering the page to show open and closed.
I used the helpful “watch” command to look at the GPIO pins and they were set to IN and 0v. They weren’t registering the change of the magnet. If I manually switched them to OUT or moved the negative terminal to one of the powered GPIO pins I can see the 0/1v value change. I tried every combination I could think of, including modifying the index.php file command to get something to read (but I couldn’t).
I’m assuming something is going wrong in the "sudo raspi-gpio get $sensor_pin | grep 'func=INPUT' | grep 'level=1" command, but I’m not sure how to fix it. That or I need to add/change something to define the in/out or voltage on the GPIO pins on the new Rpi 3 Model B.
Thanks for your help!
-John
The smartest way to move forward is to cut my entire PHP stuff out of the mix. Just run this command and verify that when you’re shorting any of the GPIO pins (with GND or VCC) that one of those pin LEVELS actually change in the output:
sudo raspi-gpio get
JZ, Thanks for the quick response. I started working backwards and I think it was a combination of me not marking “true” on the contact sensor and my Mode/write settings on my GPIO. They are starting to reflect on the index.php page.
The problem I’m having now is that the Smarthings generic http device is not seeing the sensor state. I am able to trigger the momentary switch and pull the Rpi system info (cpu, uptime, memory, etc). Am I missing a step somewhere?
-John
The only part that my device does not do is that it will NOT proactively push state back to the SmartThings. That means you have to refresh the device every X minutes. Please see the SmartApp I provide which helps to refresh and keep secondary/fake devices like sensor & switch in sync with the parent device.
The alternative is to use something called Pollster from the community which will also poll/refresh every X minutes.
Hi JZst
This likes a great article, but i am stuck on these steps.
I created the devices but where do i assign the custom device handler?
I believe i am missing the step where the nodemcu ip address gets linked to the device?
Thanks in advance, is there a youtube video on this?
Your NodeMCU gets an IP and if you use the Serial Monitor in the Arduino IDE then you’d know what to plug into the Device configuration in ST.
The step you’re missing is where everybody gets stuck when first playing with ST. See one of my first posts in this forum.
The key is to add the code under ST IDE > Device Handlers then create a brand new device under ST > Devices and in one of the drop-downs you have to scroll to the bottom to see your CUSTOM/NEW Device Handler. In the required address field feel free to use some junk because I manipulate it at runtime anyway to be correct per the CONFIGURATION that you do in the ST Mobile App.
Hi JZst,
Nifty piece of work.
I the get big picture on the theory of operation, but I come up short understanding your code.
Should this version of the software just build and work on NodeMCU ESP12E?
ESP8266-12E / NodeMCU / WeMos D1 Mini WiFi & ENC28J60 Sample v1.0.20171030
I skimmed the head and tail of this long thread, but not so much in the middle to look for clues… I found I had to made changes in the .ino code to build. I see some communication between the Node MCU and the SmartThings DTH, but doesn’t work end-to-end.
You have options for if-WIFI, if-MQTT, if-this etc. Perhaps I need a simpler NodeMCU-ESP12E to DTH. Do you know a simpler code base?
I’m unsure if the code is for arduino-xxxx and not directly for NodeMCU.eg. the repeated call to EEPROM.begin(1) versus what the internet suggests for NodeMCU EEPROM.begin(size).
WRT the events from Web UI or SmartThings DTH, I see some of events messages logged on the serial monitor. I’m not sure what to expect.
232910 —FULL REQUEST—
GET /Toggle2ndSensor HTTP/1.1
Host: 192.168.1.241
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://192.168.1.241/ToggleSensor
DNT: 1
Connection: keep-alive
Upgrade-Insecure-Requests: 1
237935 —END OF FULL REQUEST—
Another quirk is when I press the DTH-event or Web-UI-button and they make events (above).
But, the ‘result’ is blank. I’m not sure how to debug this event code.
Do you have any worthwhile tips?
rp
Few things:
Thanks for well organized reply. I’ve tried.
Web page partially works and partially doesn’t. I will look further.
I understand my post is sample of n=1. Having said that, Arduino EEPROM sample code works. Observation: Web Page Toggling 1 and Toggling 2 does not.
I see approximately 9 calls to EEPROM.begin (xx) in your v1.0.20171030 code.
In sample EEPROM apps and other arduino forums I see 1 call like EEPROM.begin(512) where 512 is size of EEPROM begining used. Reading your code I feel you use 5 bytes of EEPROM, so a single EEPROM.begin(5) in setup() would seem appropriate. I can not reconcile yet, maybe repeated calls to EEPROM.begin(xx) are benign.
2b. Could the initial state of the EEPROM (~5 bytes) influence runtime behaviour?
Got it. The ifdef isn’t loading MQTT. (//#define useMQTT)
OK older versions. I have other client-server apps running OK on the NodeMCU. Are you saying there is simple example of NodeMCU-to-SmartThings in the IDE-Examples?
Sending updates won’t be a problem. I use the NodeMCU to toggle a real Z-wave device to drive smartThings. But do want SmartThings DTH to be able to communicate by polling the NodeMCU.
But like you said if the Web page doesn’t work that needs figured out first. So I’m still at step 1.
Yeah I’ve used EEPROM.begin and I do indeed use a single byte for each setting that I store in the EEPROM. I also don’t want to do begin in the setup routine because I don’t want to begin until I actually had a user request to do so. Feel free to try but doubt it makes a difference considering that the EEPROM aspect I’ve had working for a really long while and tested across many device. In fact see the difference of the Arduino code vs. the NodeMCU code in my GitHub repo. EEPROM.commit fails on regular Atmel/Arduino while you need it on the NodeMCU.
Here are a few more hints: try running via a different/better USB cable and to a different port when programming and powering the device, just in case amps are too low. Don’t forget the generic EEPROM sample that in the IDE when you install the 8266 board. Lastly, there is a slight chance that you got a busted EEPROM in your device… if you have another, definitely test with another to gain some sanity 
there’s a reason why these clone devices are cheap. I have a few that I have to use with external + & - leads rather than micro USB by itself. They definitely can and do go bad at times especially when handled often.
Thanks,
Would you copy and paste a couple examples of what you see in the ide-serial-monitor logging when you trigger from (1) the web-page and (2) the SmartThings DTH.
Serial.println("—FULL REQUEST—"); Serial.println(client.readString());
Serial.println("—END OF FULL REQUEST—");
request = client.readStringUntil(’\r’); // Read the first line of the request
fullrequest = client.readString();
Serial.println(request);
request.replace(“GET “, “”); request.replace(” HTTP/1.1”, “”); request.replace(" HTTP/1.0", “”);
client.flush();
I have not yet gotten any values in ‘request’
I do see logging between FULL REQUEST & END OF FULL REQUEST
218810 —FULL REQUEST—
POST hello_foo99 HTTP/1.1
Accept: /
User-Agent: Linux UPnP/1.0 SmartThings
HOST: 192.168.1.241:80
Content-Type: application/x-www-form-urlencoded
Content-Length: 22
MainTrigger=&MainPin=4
223817 —END OF FULL REQUEST—
Did you ever change the device’s Settings > POST or GET method and see what happens. I mentioned it in the list above, bullet 1.
Keep in mind I have MQTT on, sample log below:
New client: 192.168.0.55
GET /RELAY1=MOMENTARY HTTP/1.1
/RELAY1=MOMENTARY
Client disonnected
Message arrived [smartthings/Nice Wemos/switch] HTTP MOMENTARY requested by: 192.168.0.55
Message arrived [smartthings/Nice Wemos/switch] on
Message arrived [smartthings/Nice Wemos/switch] off
New client: 192.168.0.25
GET /MainTrigger= HTTP/1.1
/MainTrigger=Newest version on GitHub. It’s kind of an important release as it fixed so much MQTT unreliability and intermittent failures. Now the MQTT code processes after the HTML has been fed to the requester. Having in-line MQTT calls mixed in during large HTML responses to clients caused serious problems. Those problems made me add a duplicate request feature where the device handler will not respond if more than one request is sent per second. Helps to eliminate infinite loop with MQTT flipping switches on & off non-stop. Here are the release notes:
v1.0.20180502 - Lots of bug fixes. MQTT logic optimized eliminating intermittent issues with large HTML client responses while doing MQTT execution in-line. Added ability to limit frequency of requests. This helps with MQTT infinite loops with on & off constantly triggered. Reliability should be much better with this version.
Enjoy!
It’s been a while! Looks like you’ve made some changes. I finally got tired of hearing Alexa say “smartthings isn’t responding” and updates to the latest version of your app.
I was wondering if you could help me out. I’ve got my contact sensor reconfigured to match your new requirements, and the PHP page is accurate and responsive to changes on the sensor. But, I cannot, for the life of me, get the contact to update in the Smartthings app! I’m beating my head against a wall! Any ideas? I’m sure I’m just overlooking something.
Thanks!
Looks like it’s my fault… when modifying the sensor code I only did that for Arduino and forgot to make sure that PHP works. Please grab the latest version of the Groovy DTH again and you should be good to go.
It’s working now! Thanks for updating!
As an FYI, I re-wrote and optimized a bunch of stuff for the ESP32. The reliability is awesome and wifi recovers. It’s super fast… and more importantly, no more HTTP repetitive polling to update the status of a sensor/switch. Everything is dependent on MQTT bridge and here’s the stuff I have working fully: 2 switches, ability to use a momentary button on each switch, 2 contact sensors and temperature/humidity from BME280 and DHT sensors. The big improvement is that the tiny OLED on the Heltec Wifi Kit32 board or the Wemos LoLin makes things much more polished. I tried to use all default simulated DTH’s available for ST. Switch from the sample DTH, momentary button had to be hacked a bit in order to work. Contact sensors were the nasty piece because ST makes those read only so have to sync status of the sensor with some hidden switches. Anyway, all works flawlessly and I’m close to being open to releasing it for a beta run. Not sure who’s interested but it’s way more powerful/responsive/immediate than my previous project above. Let me know if interested in testing…
Here’s what it looks like in my garage with a 5v dual relay board (garage door & light). The OLED does show different screens for dual switch and dual contact states.
