-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Technological choices #5
Comments
I don't have any opinion on this. We may ask @lorossi and @MauroMombelli perhaps if they have anything to add |
ok so for MQTT the libraries will be :
|
Why did you pick these two libraries instead of the more common PubSubClient for esp32 and mosquitto for the server side? The choice is fine, I'm just wondering if there is any reason to not use the two most widespread libraries/softwares |
I actually used mosquitto on PC to test the ESP32 client library, it is easy to use. But I was hoping to have only one python program (without external programs) for server side, using Python libraries for Database, web server, MQTT broker. But maybe that's a wrong approach. I don't know if it's easy to "bundle & configure" things in Raspberry Pi. For ESP32, I picked 256dpi/MQTT because it seems actively maintained (PubSubClient last commit is 3 years ago) and it was available in platformio repository. Licenses are the same (MIT). I can easily change to PubSubClient if this is a more common choice. |
Now that I have a Raspberry Pi Zero, I understand better the approach. Mosquitto is running fine on Raspberry and I will use it as broker. |
The current implementation has an MQTT client only with MongoDB database. There is no MQTT broker for the boards to connect. In my opinion a"self-contained" python server with minimal external dependencies could be desiderable.
Protocols for the boards, options I see:
For database, options I see :
My personal preference would be API REST + SQLite.
The text was updated successfully, but these errors were encountered: