MicroPython Forum (Archive)

This is partly micropython related and partly just a general question about good practices since I'm new to both micropython (but not regular python) and microcontrollers and sensors... I've done past projects with Raspberry Pis, but those are basically full blown computers so working with them is different.

My project here to know when my washing machine finishes a cycle, both via an alert, and also being able to query the status from another device. For this I have an esp8266 board and a vibration sensor with digital output. I've mounted the vibration sensor on the back of the washing machine and connected to the esp8266, and have done enough playing around in the REPL to determine that it definitely can detect vibrations when the machine is running. So the hardware setup seems fine.

The goal is to have the device running a loop to detect extended periods of vibration, indicating the machine is running, or extended period of no vibration, indicating that the machine is stopped. At the transition between the two, it will send an alert.

The above seems straightforward with just doing things in a loop, but... I would also like it to possible to query or poll the device, maybe with an http API, to find out what the current state is: washing or stopped.

That seems to get more complicated: how do I have it listening for an incoming connection while also doing the washing machine state checking loop?

Also this goes back to the general question of what the best/recommended/standard way is to get information from a remote device like this? Is it customary to pull data from it like with an http API? or to have it send data to another service waiting on another device?


Thanks,
robo

As you are familiar with python, you may know asyncio. For micropython there is uasyncio, a smaller version of it. Makes it possible to to thing asynchronous instead of having a fixed loop.
For communication I always refer to using mqtt. There are micropython clients for it and there are good server for linux, e.g. Raspberry PI. As a frontend you can use homeassistant.

Google's Firebase may be nice here.
You can sign up to the API and use the CloudMessaging Services.

Then you can code an app pretty quickly in Kotlin or Java for android based devices and maybe even use the Firebase Cloud Messaging API to push to both your android apps/devices and even web browsers:
https://firebase.google.com/docs/cloud-messaging

Once you have signed up and created an account with firebase, you can then send push notifications using the API.
https://firebase.google.com/docs/refere ... sages/send

You can send a request dirctly to the Firebase API to send the notification from the ESP8266 using sockets:
https://docs.micropython.org/en/latest/ ... k_tcp.html

Guess that's a nice approach if you don't care that google will get your data and if your data only flows from the esp8266 to the service.
But it's true that the one thing I find lacking using mqtt is the possibility get "cheap" push notifications. The mqtt clients on Android are not really well at that, they are either slow or use a lot of mobile data to keep connected.

kevinkk525 wrote: ↑

Sat Dec 22, 2018 9:08 am

Guess that's a nice approach if you don't care that google will get your data and if your data only flows from the esp8266 to the service.
But it's true that the one thing I find lacking using mqtt is the possibility get "cheap" push notifications. The mqtt clients on Android are not really well at that, they are either slow or use a lot of mobile data to keep connected.

At work (Java/Android/SpringBoot dev) we use a queuing service call ApacheMQ to have a data/message BUS between servers.
The broker (the instance that manages/holds the queues) should really have 100% uptime and not be changing location/IP all the time.
As far as running a client on the phone...you should expect a client will always be trying to sub to the queue it has been told to, especially when it has been installed as a service on the Android device, always using data to stay connected to and receive queued messages.

PS: ApacheMQ will accept MQTT protocol:
http://activemq.apache.org/mqtt.html

I'd build something like this using free/open source stuff. Mainly because I use it at work I am familiar with it. You'd need to pay for the AWS Nano instance and RDS though...the rest of the stack is "free"/"open source".

If I wanted an all out cheap solution for a "hobby project"...the Pusher API set is nice. They provide Notifications and WebSockets.
https://pusher.com/
They have a free tier...and it is generous. Very generous for a person on their own hobby project.
https://pusher.com/channels/pricing - Channels (Web Sockets) Pricing...
https://pusher.com/beams/pricing - Beam (Notifications) Pricing...scroll down for free tier allowance.

Then you'd want an Amazon Web Services Nano EC2 instance to crate a web server and have an ApacheMQ broker installed:
For a year: https://aws.amazon.com/ec2/pricing/rese ... s/pricing/
The RDS (Database): (The costliest bit...but also kinda optional depending on architecture you go for...)https://aws.amazon.com/rds/mysql/pricing/

Id' then Install Tomcat and ApacheMQ on the AWS Nano EC2...both free open source Apache WebContainer and Queuing system.
In the Tomcat I'd run a SpringBoot Application.

So all in all, you'd have:
A) A web facing API for your app to get Data.
B) Web sockets for real time while the Android App/Web App is connected and running/open.
C) Notifications can be sent when certain events happen (if the app is in the background/closed for example).



Possible Option:
1. MQTT packet is put on apacheMQ "InQueue".
2. SpringBoot picks up the message form the queue. Persists it straight in to the database for "persistence".
3. Spring boot monitors queues and makes decisions to send Notifications based on data (say an unusually high value for Temperature comes in).
4. Spring boot also deals with API requests such as POST/GET so you can make mobile/webapps that can get data from your sever and display it.
5. The Pusher Channels can be used for "live data" when a mobile or web app is connected to the server.

Thank you for all the suggestions! Some of those are... quite big projects But great info.

I'm actually an iOS user, not Android, not that it makes a big difference for most of this. I'll look into the async library, but it sounds like generally accepted solution is to have the sensor device push information to a server running a broker. I have a couple always-running linux boxes at home and I'm familiar with AWS so something cloud based is another option.

FWIW, I have a pretty functional basic POC running now, sampling the sensor data and sending a push notification to my iPhone via an API call to Prowl (https://www.prowlapp.com/).

Current issue is that my esp8266 device reboots every 5-10 minutes when on USB power... connected to a bench power supply on 5v or 3.3v it's rock solid, but all the USB power supplies I have seem to not make it happy.

The problem with usb bench power suplies is that they have cut-off the power once the amperage gets too low. I have the same problem with my bench power supply. Using the low speed charging port makes it a little better but the esp8266 just uses not enough power to keep the bench active.

The architecture I provided is monolithic...But for a small hobby app it is plenty. But you can easily make new IoT devices and use the same set of services to provide a new app. Once the stuff is in place...you have a decent stack that is pretty scalable.

robo wrote: ↑

Sat Dec 22, 2018 7:15 pm

Thank you for all the suggestions! Some of those are... quite big projects But great info.

I don't know your experience, but I have almost made my little Framework for EPSs to get them to push to a queue.

The server side stuff at home I have just set on an a RaspberryPi "stack". One with MaraiDB/Mysql, one with Tomcat8 holding the Springboot app (it only persists the messages to the database at the moment) and one with ApacheMQ (that holds the queue).

I am leaving it on for a few days...out internet goes out randomly and all sorts...so i have the ESP32 being logged by putty on one RaspberryPi.

If you have any interest, I could give you a GitHub link to my basic set up...
As far as putting it on the cloud, it is the same process really...so when done, I can maybe put it globally in a day.

For starting with basics to get and post the sensor values to Real-time Database Firebase mention below link will help you out.

https://www.hackster.io/varuldcube100/s ... ase-4d6b83