Closed balloob closed 7 years ago
This seems like a move from the controller space to the device space. I'm struggling to see the advantage over the standard Arduino C++ and MQTT approach.
Micropython will support MQTT natively. Also, it seems easiest to just setup the client to POST to an endpoint in HA instead of polling it. Thoughts?
@SEJeff I phrased it wrong. I meant that uHA is responsible for polling the sensors so it can publish this data to HA. I've updated my description.
@happyleavesaoc I see it as a natural extension to the Home Assistant platform. Support for uHA would be implemented as components and would only help in improving the multi-instance experience. Yes, there are alternatives that people can use today but they are more complex. I would love to offer something that has a very low barrier to entry, something that is just as easy to use as Home Assistant. I must admit that I also just love playing with new technology and platforms so there is that :sunglasses:
Example of how I can see this working:
import time
from machine import Pin
from uhomeassistant.core import HomeAssistant
from uhomeassistant.components import DHT22
# Initialize pin 2
led = Pin(2, Pin.OUT)
led.low()
# Initialize Home Assistant with a name
hass = HomeAssistant('living_room')
# Add a component. Pass in pin number in constructor
hass.add_component(DHT22(10))
# Register a service
def flash():
for i in range(10):
led.high()
time.sleep(0.5)
led.low()
time.sleep(0.5)
hass.register_service('flash', flash)
# Will discover HA server, start publishing data, listen for service calls
hass.start()
Awesome... let's do this!!
How will components be represented in main instance? If they comunicate through REST API, will we need new platforms for this, like switch.esp8288_uHA, light.esp8288_uHA, etc? If MQTT is prefered protocol we already have platform for most components... but I like the solution where we could discard mqtt broker, and have this working only with HA and uHA...
A nice addition, already thought to be usefull for other purposes, is the home-assistant cloud services... we could host a private cloud area to manage esp8266 devices, OTA firmware upgrade, etc..
Initially I would expect to not have the main instance know anything about it - there is no need for it. Just have uHA write states using the REST api.
I've used an ESP8266 device with Espruino to get data in using MQTT as sensors. I love this idea.
For discovery and more, using CoAP may be a good idea. This is a pretty nice fit. https://tools.ietf.org/html/rfc7252. There's also already aiocoap for python, which should be a nice foundation.
Being relatively new to HA and being heavily invested in ESP8266 platform, the concept of uHA is awesome. Most of my sensors/buttons/lights run on the ESP8266 NodeMCU via MQTT which I found to be more complicated to setup than I would like.
Not really knowing the technical side well, I can only speak to what I think it would take for widespread adoption.
1) Easy setup - I assume most novice users will go after the Huzzah ESP8266 variant (or NodeMCU if supported). It's not clear to me how Micropython or uHA will be installed and configured. @balloob's sample script above looks great, but I don't see any WIFI configuration information. One simple script configured with something like the Arduino IDE would be awesome!
2) Auto discovery - uHA and HA need to find each other without any trouble.
3) Getting rid of MQTT. If these devices can communicate without a 3rd party MQTT broker, that's huge in simplifying the setup.
4) Clear and direct tutorials for setting up simple IoT devices. @balloob's blog post about his DHT Huzzah device was great for pointing me in the right direction. I think if we had 5+ articles on ESP uHA devices it would make big rounds on various Reddit and niche circles. I'm happy write up some of the devices I've made (party button, blinds, LED notifications, sensor nodes, etc) and port them to uHA once available.
Not to get off topic, but one way we might be able to increase the HA community is to make some kind of user submission form for IoT devices. I don't think most HA users know how to work GitHub well enough to submit pull requests and update the website. If we had some submission platform that made it easy to send a text and a couple of pictures that could then make it into the official website, I'd bet you get dozens of people contributing IoT ideals, scripts, etc.
uHA sounds like a great idea. This is what I was considering would make for a great guide on the best way to get someone to try out home automation without investing more than $50 (or Euro): Set up HA on Raspberry Pi Set up uHA on ESP8266 Connect DHT22 to ESP8266 Connect to ESP8266 via Wifi (SSID: uHA_configure_me, no password) Select wifi and enter password in web interface, select sensor: DHT22 and GPIO pin, give it a name (MQTT topic), save ESP8266 restarts, connects to the wifi, automatically discovers HA and starts sending temp/humidity data.
Compared to other home automation solutions I've seen this would lower the bar significantly. For extra credit we could offer a pre-configured DietPi image to turn this into almost a zero-configuration scenario. To be honest I am split about whether the REST API would be better or MQTT (maybe together with this enhancement). MQTT would potentially make it more easily extensible and easier to play nice with other IOT projects.
The kickstarter campaign is looking for suggestions for more stretch goals. Anyone got any suggestions for making uHa a reality then this might be the time.
Copy of the latest post for reference
Hi backers.
Today we surpassed 1000 backers and GBP 20,000 worth of pledges. That is amazing! And it means that there will be some more very cool features implemented for the ESP8266: a micro database, and support for native code and inline assembler.
We have been thinking hard about further stretch goals, because we know that more features will make using MicroPython even more fun. Here is what we came up with:
At GBP 23,000 we will add support for running "upip" on the ESP8266. upip is a package manager for MicroPython modules (similar to CPython's pip) and will allow you to install Python modules on your ESP board's filesystem directly from the internet (without it, you would need to download needed modules manually to your PC, unpack them, and then transfer to your module - upip automates these steps).
At GBP 26,000 ... well, we have a few ideas: maybe cloud integration, maybe uasyncio support, maybe something else. Please keep your ideas coming too!
Has there been any progress on this? I saw one github project.
There is this https://github.com/home-assistant/micropython-home-assistant
But not much work has been done on it.
This post is meant to start a discussion, please give feedback!
MicroPython is currently running a kickstarter to add ESP8266 as an official supported platform. Not only has it been funded, they also made it to their stretch goal to release their initial code after the campaign finishes on the 2nd of March. They added a pretty awesome stretch goal of GBP 15,000 to provide drivers for a wide range of popular sensors. With almost a month left I'm pretty sure they will reach that too. This will be awesome as it means we only have to make sure we get the data into HA.
It's time to start thinking how we can make it as easy as possible for people to integrate their ESP8266 with Home Assistant.
Some resources I've found to be useful:
I will refer to HA as the main instance and uHA as the instance running on the ESP8266.
First let me list non-goals of supporting MicroPython:
Publishing information from uHA to HA using Rest API (=MVP)
This will be the first priority. Getting sensor information from uHA to HA. Just getting the data out there will be easy as we can use the Rest API provided by HA.
Some things that should be included/considered:
Discoverability
We want it to be trivial for users to connect their ESP8266 to Home Assistant. We should be able to automatically create a link with the main instance. This can be done either using uPNP or another broadcast protocol.
We have to take security into account here as HA can be password protected.
Allow calling services on uHA from HA
The ESP8266 should be able to register services with HA. We should probably namespace these services using the ESP8266 instance name as domain.
I am not sure what we should use to communicate from HA to uHA. This should be researched further.
To consider:
MQTT is not an option here because we don't want to depend on a 3rd party message broker.
MQTT
This depends on the availability of an MQTT client module for MicroPython.
For all the former steps, we should be able to switch to MQTT too. A drop-in replacement for the communication with HA to communicate with MQTT.