Smart home tech is on the rise, but cost or lack of specific functionality may give pause to prospective buyers. [Whiskey Tango Hotel] opted to design their own system using a Raspberry Pi and Bluetooth device connectivity. Combining two ubiquitous technologies provides a reliable proximity activation of handy functions upon one’s arrival home.
The primary function is to turn on a strip of LEDs when [Whiskey Tango Hotel] gets home to avoid fumbling for the lights in the dark, and to turn them off after a set time. The Raspberry Pi and Bluetooth dongle detect when a specified discoverable Bluetooth device comes within range — in this case, an iPad — after some time away. This toggles the Pi’s GP10 outputs and connected switching relay while also logging the actions to the terminal and Google Drive via IFTTT.
[Whiskey Tango Hotel] has included their Python code and build steps at the end of their blog post to help save you some time should you start a similar project. Indeed, the Raspberry Pi + Bluetooth combo can be used to great effect in many different areas — like adding non-standard functionality to your vehicle’s stereo.
Mister House software has functions for this already to look for BT devices passively or even actively. A lot of the linux Home automation projects have been doing this exact thing. I switched to using Zigbee and a keyring fob with the ZB radio in it so it triggers when I am about 100 feet away and lights the front porch lamp, the garage lamp, and the entryway lamps. that all have cheap Zigbee Cree light bulbs installed in them.
Home Assistant (http://home-assistant.io) is the python successor to Mister House, OpenHAB, etc.
It can do this, and the server even runs on a pi3, and you can use the Bluetooth sensor to trigger advanced actions (like turn on a wemo light) rather than directly toggling a GPIO.
Stop trying to spread hopes and lies.
Home Assistant _wants_ to be the successor. It has a long way to go before toppling OpenHAB. Ho.e Assistant isn’t Java. That’s about all it has going for it at the mo.ent.
A+ for trying though.
Using Python rather than Java is a big plus in my book. Better libraries, less boilerplate, no Oracle.
There should be an integrated ESP32 relay board out before the end of the year.
Don’t tell me anymore when the board is out. Tell me when it is working. ;)
There is already a WiFi only board for the ESP8266 that works, the ESP32 adds BT.
http://i.ebayimg.com/00/s/NDUwWDYwMA==/z/5p8AAOSwNSxVCBRu/$_1.JPG
Working as in: documentation, stable API, Uart HW handshake, no crashes (while driving AC devices?), no forbidden things nobody told you about or even knew about. The ESP8266 was like: “We have a chip and no idea what works. Let’s find out what features we can use at the same time without crashing the chip and unlock even more features on the way”. Too much uart->crash. To much IO->crash. xyz->crash. Also, for the ESP8266, the performances achieved are very far away from the performances that were announced.
I know the full ESP8266 story and a lot of good things came out of this. But for me, Espressif better makes it right this time. Because this time, others will provide alternatives and I am running out of patience regarding spending time on evaluating this.
So, the community worked out the ESP8266. There was even a micropython-kickstarter project. But what is Espressif thinking? Maybe “Well, that went well, lets do it again, just a little bit different. So we start by sending the boards to a VIP community. And lets start announcing great features, great performance and great stuff. People will talk about those announcements everywhere, even if we don’t have a working product yet and maybe never will have in the way that we announced it”?
For the relay board the limiting factor would be the mechanical relays, the ESP can easily do what is required. Now if they were solid state relays you could really do some interesting things and the ESP would need to work harder, but even then for such a simple task it is not going to be over worked, so your “issues” are irrelevant, even if they were real.
Interesting that you label mechanical relays as being the limiting factor when talking about a MCU. If I am only allowed to switch the relays, I could also buy an available product.
No, the limiting factor is running into problems that are caused by bugs, lag of documentation, a.s.o. Yes, this is somewhat better with the ESP8266 nowadays. But IMHO, you are very optimistic that, once the ESP32 is out, we can immediately use all its features the same way as we can use ESP8266 today. Who knows how complicated (buggy) it will be to use WLAN and bluetooth in the same project? Will the announced power requirements hold? a.s.o… Alternative products work better from the start with similar features and similar price range.
And that was my point in the first place: Don’t tell me when the board (is announced to) come out. Tell me when it is working.
I am also looking forward to the release of the ESP32. But so far, we have nothing but a few guys with beta ES boards and announcements. So based on what experience do you think, ESP32 will be well worth considering in projects as soon as it comes out? Because my experience tells me the opposite.
How experienced are you if you consider that the ESP would give you problems with a toy application such as switching relays? Seriously, that just does not add up, you ether know your stuff and would find it a trivial task, or you don’t know much at all. You were just complain for the sake of it, yes?
The hole point of doing something like that yourself in the first place is Individualizing, adding stuff, create something new. If you do nothing or only most trivial stuff (and not to much of it at the same time) and you have no problems. The ESP can’t barely be used for anything else than uncritical toy applications while Espressif and people in blogs imply otherwise.
So what exactly did you try and fail to do using an ESP8266?
Typo: whole
I failed:
Compiling (back in the days)
Using uart with handshake
Figuring out the maximum UART throughout w/o paket loss
Figuring out constraints on using GPIO
Figuring out exact power requrements (try and error)
Finding full docs for API calls
Figuring out how to use a custom/modified IP stack or no IP stack at all
a.s.o.
Some of those things got figured out in time by the Community. What makes you think that this will all be different with the ESP32?
I got the impression it was you and not the ESP that failed, so why do you think that will happen again? You never did say exactly what you were trying to build either.
Ridiculous. Where have you been when non-espressif-people spent quite some effort to make gcc work with ESP8266? When people made documentation for ESP8266 and reverse engineered the flash content and how to program the flash a.s.o. Read the old posts. Some of what I wrote is not solved until today because it can not be solved, only worked around. Then, who made the ports for Arduino, NodeMCU, micropython?
“What I tried to build that the ESP8266 can’t do?” Almost sounds like a joke. Tell me, where is specified, what the maximum UART throughput w/o data loss is for TCP and for UDP? (not UART loop and not IP-loop, the real thing)
How long can I use the GPIO exclusively w/o crashing an active Espressif stack or is there a mechanism to handle this and documentation that describes this mechanism? Is there at least a reliable uart handshake emulation available nowadays? …I am not looking in those documentation on a monthly basis anymore to see if some vital information finally got available or not.
Also, every time I answer one of your arguments, you are not continuing your argument (maybe because it is dead?), but you come up with something else.
All I wanted to say is: Don’t tell me anymore when the board is out. Tell me when it is working. ;)
And I am not going to say anymore on this.
My argument? I said hey there is an ESP8266 relay board already, this is a fact, not an argument, that pile of troll shit you spouted was an argument and you failed to get me to respond because I’m not stupid and in the end the truth is that you failed, not the ESP. A bad workman always blames his tools.
I’m with Lars, trying to use the ESP8266 in a well designed and managed connected system is just not possible. I tried with my home IoT system for many weeks and I could extend Lars’ crap-list two fold at least. It got to be that I had to write a self-rebooting routine to all nodes for **when** (not if) they lost “Home,” or hadn’t received packets for “x” amount of time etc. I have no doubt at a hobby level with the constant tinkering and where things are not required to work for a long time, they may be OK.
I continue to be amazed at how adamantly some people try to to defend the ESP8266 when even Espresif state many of the problems on their website and do nothing about them in the firmware. Anyway, as with Lars, my last (and only) post on this topic and I will quietly drop back into the shadows again and watch since the ESP8266 is not ready for Prime time. One can only hope they get the ESP32 right. For now, I will stay with the nRF24L01 system I have had running at home without a single wireless-fault for 172 days and counting.
Just one old fart’s opinion. :)
” I had to write a self-rebooting routine” that is called a watch dog and it is not a flaw workaround,in fact including one in your code design should be mandatory in a professional project. Nobody here is defending the ESP, I just pointed out that the ESP32 has BT so the entire project above could be handled by it alone and that a relay board for the ESP8266 already exists. Then people started defending their ideas and ways of doing things by bitching about the ESP. The Raspberry or similar boards that run Linux are no different they are all evolving and require updates, it is just that using an entire Linux system with more power the computers that got men on the moon, just to switch relays is a sign of really weak engineering skills. As for the nRF24L01, where will you get the above required BT functionality from?
Battery powered PIR sensor LED night lights are $3-4 each. They’re quite handy. I found some my Dad bought but never used. After using them for a while I’m planning to get more.
This seems to me a solution in search of a problem.
Really? PIR sensors are hard to find for less than 10
LED light with PIR sensor for under USD $6 actually under $5 for multiple units!
http://www.dx.com/p/auto-pir-keyhole-ir-sensor-4-led-white-light-lamp-1-x-aa-lr06-130798
Sound triggered LED light bulk for under USD $3
http://www.dx.com/p/zhishunjia-e27-3w-led-acousto-optic-sensor-white-light-corridor-lamp-428487
Between those two you have a lot of useful parts, you can even combine them so the PIR triggers the same circuit the sound sensor does.
Also dx.com is not always the cheapest option these days so check those product names against the listing on ebay too.
I still can see the use of all this !!!