Open michaelaye opened 3 years ago
Sounds good to me. You are right, it would change a lot of this code but that's a good thing. I also don't like the entanglement of the GUI and Comms Code.
I might dig into this, this week to see what I can come up with.
I have started to work on this and get the code decoupled. I have created a Mug class that should hold all of the values for the mug and holds all the values to control it. In the current state, I am able to control the mug and get values from the mug all via CLI using a test script. Currently, I am in the progress of rewriting the UI to work better with asyncio and my rewritten class. Please feel free to take a look at my fork for current progress: https://github.com/ethanholz/EmberControl.
Please keep in mind this is code is still very messy for me and I will be cleaning it up in the coming weeks.
hey @ethanholz thanks for sharing. Will take a look at it for sure. I also worked a bit on splitting the code up and creating a library for the communication between the computer and the mug. Maybe we can open another project for the library and work together on it.
Sounds good to me! I did find a great price of code we might want to dig into. Someone wrote a backend for this into a home assistant project, another great start for sure: https://github.com/sopelj/hass-ember-mug-component/blob/main/custom_components/ember_mug/mug.py .
Hi! Thx for your work on this. I'm facing quite a struggle with Qt on my side, so I was thinking that in general it would be really nice if the BT comms could be decoupled from the Qt GUI, so that for example, it would be easy to either get a simple command-line tool running or even a nice Jupyter notebook dashboard instead of an extra GUI. What do you think? It would however change a lot of this code, so maybe we should just fork first, get the BT comms running on their own, and later Qt users could rewrite using the BT comms repo.