Very strange… when I have a sec I’ll wipe my old RPi. The fact that you can only run rpi-update after all was installed is kinda bad as that firmware update should have zero dependencies other than on the run-times it requires — not Apache or PHP, etc.
I just reinstalled Raspian Jesse Lite following your instructions exactly. This is what happens when I try to do sudo rpi-update:
$ sudo rpi-update
sudo: rpi-update: command not found
$ dpkg -l | grep rpi-update
$
$ sudo apt-get -y install rpi-update
Reading package lists… Done
Building dependency tree
Reading state information… Done
The following NEW packages will be installed:
rpi-update
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 4,408 B of archives.
After this operation, 45.1 kB of additional disk space will be used.
Get:1 http://archive.raspberrypi.org/debian/ jessie/main rpi-update all 20140705 [4,408 B]
Fetched 4,408 B in 0s (12.7 kB/s)
Selecting previously unselected package rpi-update.
(Reading database … 31514 files and directories currently installed.)
Preparing to unpack …/rpi-update_20140705_all.deb …
Unpacking rpi-update (20140705) …
Setting up rpi-update (20140705) …
$ sudo rpi-update
*** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
*** Performing self-update
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 13403 100 13403 0 0 43250 0 --:–:-- --:–:-- --:–:-- 43375
*** Relaunching after update
*** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
*** We’re running for the first time
*** Backing up files (this will take a few minutes)
*** Backing up firmware
*** Backing up modules 4.4.50-v7+
#############################################################
This update bumps to rpi-4.9.y linux tree
Be aware there could be compatibility issues with some drivers
Discussion here:
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=167934
##############################################################
*** Downloading specific firmware revision (this will take a few minutes)
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 168 0 168 0 0 2393 0 --:–:-- --:–:-- --:–:-- 2434
100 53.9M 100 53.9M 0 0 6916k 0 0:00:07 0:00:07 --:–:-- 6415k
*** Updating firmware
*** Updating kernel modules
*** depmod 4.9.31+
*** depmod 4.9.31-v7+
*** Updating VideoCore libraries
*** Using HardFP libraries
*** Updating SDK
*** Running ldconfig
*** Storing current firmware revision
*** Deleting downloaded files
*** Syncing changes to disk
*** If no errors appeared, your firmware was successfully updated to 9e6a1a545ef33ac6cc3805845cb3ecac26514a41
*** A reboot is needed to activate the new firmware
$ sudo shutdown -r now
I followed the rest of your instructions.
I ran into the same issue. Let me know when you get a chance to wipe your old RPi.
Bad news @JMitch… working great for me. I definitely needed to alter the instructions which I did in the OP. SSH was closed off on the downloaded Raspbian image, had to use raspi-config to enable it. Obviously I had to change the order of rpi-update which has to come after actually installing it with apt-get — just like you indicated.
That’s about it… worked like a charm after wiring up and uploading my PHP. It’s a bit daunting because I can see you know what you’re doing and you’re starting from scratch just like I finished & tested a few moments ago. However, our results are not the same…
Keep looking at the code and do simple sudo echo commands to the root instead of the current gpio commands. Lastly, add sudo to the chained commands after each semi-colon.
Good luck, let us know how it goes…
Thank you for looking into this. After debugging stuff, it turns out to be user error. Oops. I should have known better.
I got confused with gpio -g and gpio commands. Both gpio -g and gpio control completely different pinouts. When I finally RTFM for gpio, I learned that -g refers to “BCM_GPIO pin numbers rather than standard wiringPi pin numbers.”
Things are now working as expected. Sorry to have you do the legwork to reinstall RPi - at least you updated the documentation about enabling SSH. I hope this helps someone else!
No problem, made me validate & modify my instructions. It’s definitely BCM (Broadcom) pinouts that I use. However, I completely agree, RTFM n00b 
thanks for providing the feedback on the fix so we’re all clear on the resolution.
Hey @JZst I just found your project and am hoping to leverage it to bring more value to my latest project found here:
I think doing this will allow for an amazing two-way panel capability - I can envision all sorts of possibilities. Would love to hear your thoughts.
Hi @kewashi that looks pretty damn cool! The biggest issue as you know with my code is that it’s poll-only. I realize I can place some REST status updates but that has been on the back-burner. I’m mostly relying on every-X minute refresh for status updates — which is available in my SmartApp which syncs secondary switch and secondary contact sensor. Let me know what you had in mind and I’ll see the feasibility. Very nice work though and something I’ve been considering on a wall-plate tablet. One suggestion, hopefully you can embed camera streams along with button/light statuses. That’s always been the grand vision.
Thanks - it has been a labor of love. Fun work. I also am limited to polling to update the tablet tiles. Hope to change that soon. Button and switch status are already included. I have images and video streams high on the todo list. Still images will be easy. My experience with live cameras is not very satisfying so I may skip that. With your library I think I can subscribe to events and then push an update to a tile dynamically. Sounds good in theory - we will see.
So something strange has happened. After working for a long time, my ESP8266 just closes the relay as soon as it starts up, and stays that way. This leaves my garage door open, with no way to close it unless I unplug the ESP8266.
Any idea what’s gone wrong?
edit: Oh I see, the 5V relay switch got triggered. How could that accidentally happen?
Very strange… if you’re using the latest version then the setting is in the EEPROM in the 5th byte. Search the code for eepromUse5Vrelay ---- very weird and makes me question the volatility of that EEPROM.
And now it seems unable to stay up for more than a couple of hours before dying. Could this be anything else other than a bad 8266. I’m terrible at soldering and am recoiling at the thought of having to try and do it again.
Try giving it a really good power source, 1 Amp or more and the nicest USB cable you have. Power has always been an issue for those chips.
For my 2 cents: why solder? Buy a pre-made item like the NodeMCU and just plug stuff in. I only solder things like my FET board with two inputs and two outputs. Things I know will likely stay static. Unfortunately SOC devices are too cheap to be ultra reliable hence the pre-made concept.
Well for one, mine is a bit different. In addition to the relay for the button, I’m using a FET so that I can tap into the door switch to check it’s state.
I swapped the power with a nice stock one from my Chromecast, but I’ll try and swap the cable too.
I see… I would still go with posts/rail of pins where I can press my NodeMCU or D1 Mini into like a shield. Reliability and long life on these things is something I don’t expect given the price point. Definitely dispensable items IMO.
If you happen to have a wiring diagram for your setup and brand of garage motor you use (which I think you shared above) that’d be pretty cool to see… but I realize most folks don’t draw wiring diagrams when implementing semi-ready code like mine that’s called extra work. Your set up sounds pretty nice though! I should check to see if I get different voltage on open vs. closed on the back of my LiftMaster buttons. Good luck, let me know how you work this out…
So I don’t have a drawing, but I’m using a Genie garage door opener. The relay is hooked up to the button as you describe above. I have a FET (2N7000) hooked up as such:
Source: Ground
Gate: Door open sensor wire
Drain: Wemos
One thing I’d like to figure out is how to adjust the DHT so that if the sensor wire is closed, the button in the GUI shows closed (and vise-versa).
I see so your garage motor has a dedicated sensor wire for open/closed. That would have been awesome but I got what I got… Older LiftMaster/Chamberlain don’t have this.
As an FYI, I already have logic for magnetic contact sensors. Why not use that for your FET’s drain instead. You can also “invert” the signal from open to closed. Everything you’re looking for should be addressed AFAIK.
Thanks!
Not a dedicated wire. It’s really just the switch that tells the motor to stop running. It has one for closed and another one for open. I just tied into the closed switch.
Not sure I understand about the contact sensors. I am using your code for the sensor.
I see, so you’re already using the sensor with my device just through a FET so that the ESP8266 correctly construes the signal on the IN pin. Makes perfect sense…
I checked my LiftMaster and the only thing I was able to “sense” was that 16.2V of DC current on the garage switch leads when the light is on while 16.7V is what I get when the light is off. So that’s kinda cool and gives me a bit more control. The problem is how does that fit this project or does the project not fit me anymore
There is no switch that the trolley trips to tell the opener its hit the bottom? My opener is about 20 years old, so maybe they’ve changed a bit since then…
I am very interested in this project, but have a few (hopefully) easy questions:
- Is there a reason you aren’t using the micro USB power plug built into the nodeMCU?
- Would it be possible to tie in a simple motion detector (something like this: https://www.amazon.com/dp/B00FDPO9B8/_encoding=UTF8?coliid=I1ZWM0NVYMLO6V&colid=1XY9XTLNMS4I4 ) rather than the thermometer and have SmartThings utilize it as a normal motion detector - control lights etc… (there was mention of SmartThings only seeing one “main” function, but I’m not sure if that means it couldn’t use the motion for triggering things or not).
- Other than the obvious price savings and the fun of learning, is there any advantage to making this rather than using a z-wave relay (https://www.amazon.com/dp/B00ER6MH22/_encoding=UTF8?coliid=I23WN1AH0PDDD6&colid=1XY9XTLNMS4I4)? Any disadvantages?
- You have yours wired into your actual button by the door, would it be possible to wire it into the opener unit hanging from the ceiling? The GoControl unit in #3 seems to hook directly into it up there, and it would be more out of the way up there.
Other than those questions, I think this project is awesome, and will hopefully give me and my 11 year old son something to start learning basic electronics with!