greed2411 / central_electric

Get paid 🤑 whenever sensors/io detect that there is a powercut.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Central Electric

celc.png

Coming from southern states of India, we have faced several mass-powercuts and still do. It's far better nowadays, but there have been days when we've had powercut like 9am-5pm on saturdays, or alternating 3 hours during daytime in the rural areas.

So a just a wishful thinking project 🧞, that one day we can get paid during those times. Of course the money is coming out of State's Electricity Board. Why? Just to add more skin-in-the-game 👦🔫 from their (TNEB) end.

The name of the project comes out as a play-of-word from the organization General Electric, and the new and upcoming decentralized oracle based blockchain systems.

Developed these kind of thoughts (decentralized insurance use case) after witnessing æternity's first hackathon. The project from that point-of-view is, you get paid 🤑 whenever sensors/io detect that there is a powercut.

Application

The application is pretty simple. It serves the user (imaginary) from terminal only as of now.

  • the device.py websocket-streams disconnection (a python process) of powercut.
  • the user.py can see the incremental addition of rupees to his account every second (yes again streaming).
  • the app directory has a server which accepts all sorts of user and device websocket connections.

From a learning point of view, I've always wanted to build a streaming application. Just got the simple chance to build it.

From frameworks pov,

  • my very first FastAPI (a)sync application.
  • my very first SQLAlchemy + SQLite ORM application.
  • lol even a very first websockets application using asyncio.

Architecture Diagram

central-electric.png

The architecture may feel unnecessary and over-complicated. For the lack of goroutines and channels equivalent in Python, this is the way I felt.

Each device sends timestamp and lapsed time in seconds, every second over websocket. Which the server, stores in db as events & adds an accrual interest (non-linear) to the user's device over time.

Then these events are pushed to rabbit-mq, consumed (literally just ping-pong) by consumer, later sent back to the server, to the active user websocket route.

Basically this solves the problem of: I'm getting a stream of events, I want to analyze them, then send it to somebody else as a stream in real-time.

This is a good article on what all exist out there for this problem. Notable ways of handling it were: MQTT, WebSockets & Server-Sent-Events.

BTW

I thought this would scale fine, but encountered a bottleneck, the websocket opened by consumer with server doesn't last forever / long-lived. Ran into Broken Pipe Error 🧑‍🔧, since there was a situation even thought the websocket connection was global, there was rabbitmq's callback happening on every event payload. which started messing it up. therefore, the consumer establishes new websocket connection with the server on new events (lol ik).

I still wanted to refactor this project with pure async coroutines for handling new requests, but meh. the pure def sync functions are called using a threadpool, so i assume it's fine for now.

About

Get paid 🤑 whenever sensors/io detect that there is a powercut.


Languages

Language:Python 99.1%Language:Shell 0.9%