You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Based on previous discussions, Miner and Miner Controller can be merged. Considering that there can't be a miner without a controller, and having a controller without a miner wouldn't make sense, this can currently only be done from the frontend by creating a single configuration process for the miner/miner controller that saves both.
The same goes for Energy Source and Energy Monitor, which can be merged by creating a single configuration process.
After a thorough dive with @riccardoaran, the most widely accepted hypothesis was to modify the menu items as follows:
Energy: A single menu item that includes all the system's energy elements, unifying the configuration for the Energy Source, Energy Monitor, and Forecast Provider, which will form an entity we could call the Energy System.
Mining: A single menu item that includes the Miner and Miner Controllers, creating an entity we could call the Mining System. In the future, the single menu item may be expanded to include information from the mining pool — as soon as the Mining Performance Analysis component is implemented in the core.
The hypotheses under consideration also led to the name "Energy Plant", a much more comprehensive and fitting name, which conveys the idea of an energy production plant, but this name is closer to an industrial context. The basic idea, and the spirit of Edge Mining, is to associate mining with everything that revolves around the home environment, even in the terminology.
We were also considering alternative names for Optimization Unit and Optimization Policies. The idea was to simplify the terminology, so:
Optimization Policies could become Policies.
Optimization Unit could become Unit.
While removing "Optimization" from "Policies" still conveys the meaning of what they do, removing optimization from "Unit" doesn't convey the same sense of meaning. Policies are, in fact, a collection of rules that allow a miner to be turned on and off, and the name conveys this idea well. The "Optimization Unit" is a container that aggregates policies, miners, energy systems, and notifiers into a single container, allowing each element to be connected to each other with the aim of optimizing energy waste. A candidate that simplifies the name could be "Smart Unit", which conveys the idea of an intelligent unit that allows the elements to communicate, but the term "smart" is widely used in often different contexts and hasn't convinced us much.
We’d love to hear your thoughts on this direction, especially regarding whether unifying the Energy and Mining elements under these macro categories feels like the right move for the UI flow. We are also still weighing the terminology: while "Energy Plant" is technically fitting, we’re concerned it might sound a bit too industrial for the home-centric spirit we’re aiming for, so we’d welcome any alternatives that feel more residential. Similarly, we’re curious to know if you think "Smart Unit" hits the right balance of simplicity, or if we should stick with "Optimization Unit" — unless you have a different name in mind that captures the essence of energy coordination without being too wordy. Let us know what you think! @sebailfico@GitGab19
Hi team, and thanks @markoceri for having already put together a recap of our deep conversation yesterday.
After thinking a lot about the UI terminology, I’ve decided that I don’t want to change the terms Marco introduced (such as energy monitor, energy source, mining controller, etc.), but rather define higher‑level groups that contain them. This way we can introduce a new terminology that goes hand in hand with simplifying the configuration flow.
The word “system” seems to best represent the grouping of the elements in the energy and mining categories, because they are in fact systems composed of several parts. For this reason I’m proposing the terms “energy system” and “mining system” as sets of smaller elements that together form a complete, usable system.
So, conceptually:
Energy Monitor + Energy Source + Forecast Provider = Energy System
Miner + Miner Controller = Mining System
A system includes all hardware and software elements that communicate with each other. If in the future we add more elements, the system name will stay the same and simply include the new components.
In the sidebar this could translate into showing only the top‑level entries “Energy” and “Mining”. Inside each of them, we would have buttons like “Add Energy System” and “Add Mining System”, which would open a full configuration view that includes all the elements listed above.
Regarding Optimization Units and Optimization Policies, I’ve come to the conclusion that simplifying the terms without changing them radically is the best choice, also for smoother internal communication.
“Optimization Policies” would become “Policies” and “Optimization Units” would become “Units”. They work as a kind of shorthand for Marco’s original full terms, without distorting their meaning.
I’m also not a fan of the word “Smart”, because it feels generic and overused in many current contexts.
Since I’ve noticed that the "optimization unit" and its simplification into "units" are what bring the most doubts and complications, I’ll try to clarify my idea with this dictionary definition:
In English, the word "unit" has a specific meaning that goes beyond a simple element or component. In many real-world contexts, a unit refers to a self-contained, fully operational entity made up of multiple parts that work together toward a single purpose.
This is exactly what an Optimization Unit is in Edge Mining: it brings together an Energy System, a Mining System, a Policy, notifiers, and other components into a single, operational configuration. It is the top-level concept — the point where everything converges and the system becomes actionable.
For this reason, "Units" as a UI label is not generic or vague. It carries a precise meaning: a complete, self-contained configuration that unifies all the other elements of the system.
To conclude, this is my proposed terminology for the UI, and specifically for the sidebar:
* Dashboard
* Units
* Policies
* Energy
* Mining
* External Services
* Notifiers
I like this new terminology a lot, I just have a doubt on the term "Units" because, if I put myself into a new user's shoes, I wouldn't grasp the meaning, but at the same time I think it's better to change the term "Optimization Unit" because it isn't clear in the same way.
As the "Unit" acts like an aggregate of the various entities, there is an implicit logic hierarchy between the unit and it's component, which may be reflected somehow in the sidebar.
Right now the most useful suggestion that comes to my mind would be to have the various entities like Energy, Policies, Miners to be child of the menu entry "Units". Or otherwise to have a new Units views with the various section, each section having the possibility to add or remove the various entities, which will be displayed as cards.
In this way, the Unit page would be a full overview of the actual Unit, instead of it being fragmented over multiple views.
Doing so, the UI/UX would reflect 1:1 the hierarchical relation between the entities and their container.
Also, now that we display entities as "cards", we could fit them more easily into a single page rather than the old ugly tables.
I'm aware that this suggestion is very messy, wide and could bring to a redesign of the UI, but I think it's worth sharing.
@sebailfico
I really like your proposal and I think your reasoning is absolutelylogical, especially the idea of reflecting the hierarchy between Units and their components directly in the UI.
For the 0.1.0 milestone my suggestion would be to keep all the sidebar entries on the same level (as peers).
Once we have some real usage and feedback, we can better understand how people actually navigate the app and then explore a redesign along the lines you’re suggesting, with Units acting more explicitly as a container view for Energy, Mining, Policies, etc.
Activity
markoceri commentedon Apr 7, 2026
Based on previous discussions,
MinerandMiner Controllercan be merged. Considering that there can't be a miner without a controller, and having a controller without a miner wouldn't make sense, this can currently only be done from the frontend by creating a single configuration process for the miner/miner controller that saves both.The same goes for
Energy SourceandEnergy Monitor, which can be merged by creating a single configuration process.reference #27
markoceri commentedon Apr 9, 2026
After a thorough dive with @riccardoaran, the most widely accepted hypothesis was to modify the menu items as follows:
Energy Source,Energy Monitor, andForecast Provider, which will form an entity we could call theEnergy System.MinerandMiner Controllers, creating an entity we could call theMining System. In the future, the single menu item may be expanded to include information from the mining pool — as soon as the Mining Performance Analysis component is implemented in the core.The hypotheses under consideration also led to the name "Energy Plant", a much more comprehensive and fitting name, which conveys the idea of an energy production plant, but this name is closer to an industrial context. The basic idea, and the spirit of Edge Mining, is to associate mining with everything that revolves around the home environment, even in the terminology.
We were also considering alternative names for
Optimization UnitandOptimization Policies. The idea was to simplify the terminology, so:Optimization Policiescould become Policies.Optimization Unitcould become Unit.While removing "Optimization" from "Policies" still conveys the meaning of what they do, removing optimization from "Unit" doesn't convey the same sense of meaning. Policies are, in fact, a collection of rules that allow a miner to be turned on and off, and the name conveys this idea well. The "Optimization Unit" is a container that aggregates policies, miners, energy systems, and notifiers into a single container, allowing each element to be connected to each other with the aim of optimizing energy waste. A candidate that simplifies the name could be "Smart Unit", which conveys the idea of an intelligent unit that allows the elements to communicate, but the term "smart" is widely used in often different contexts and hasn't convinced us much.
We’d love to hear your thoughts on this direction, especially regarding whether unifying the Energy and Mining elements under these macro categories feels like the right move for the UI flow. We are also still weighing the terminology: while "Energy Plant" is technically fitting, we’re concerned it might sound a bit too industrial for the home-centric spirit we’re aiming for, so we’d welcome any alternatives that feel more residential. Similarly, we’re curious to know if you think "Smart Unit" hits the right balance of simplicity, or if we should stick with "Optimization Unit" — unless you have a different name in mind that captures the essence of energy coordination without being too wordy. Let us know what you think! @sebailfico @GitGab19
riccardoaran commentedon Apr 9, 2026
Hi team, and thanks @markoceri for having already put together a recap of our deep conversation yesterday.
After thinking a lot about the UI terminology, I’ve decided that I don’t want to change the terms Marco introduced (such as energy monitor, energy source, mining controller, etc.), but rather define higher‑level groups that contain them. This way we can introduce a new terminology that goes hand in hand with simplifying the configuration flow.
The word “system” seems to best represent the grouping of the elements in the energy and mining categories, because they are in fact systems composed of several parts. For this reason I’m proposing the terms “energy system” and “mining system” as sets of smaller elements that together form a complete, usable system.
So, conceptually:
Energy Monitor + Energy Source + Forecast Provider = Energy System
Miner + Miner Controller = Mining System
A system includes all hardware and software elements that communicate with each other. If in the future we add more elements, the system name will stay the same and simply include the new components.
In the sidebar this could translate into showing only the top‑level entries “Energy” and “Mining”. Inside each of them, we would have buttons like “Add Energy System” and “Add Mining System”, which would open a full configuration view that includes all the elements listed above.
riccardoaran commentedon Apr 9, 2026
Regarding Optimization Units and Optimization Policies, I’ve come to the conclusion that simplifying the terms without changing them radically is the best choice, also for smoother internal communication.
“Optimization Policies” would become “Policies” and “Optimization Units” would become “Units”. They work as a kind of shorthand for Marco’s original full terms, without distorting their meaning.
I’m also not a fan of the word “Smart”, because it feels generic and overused in many current contexts.
riccardoaran commentedon Apr 9, 2026
Since I’ve noticed that the "optimization unit" and its simplification into "units" are what bring the most doubts and complications, I’ll try to clarify my idea with this dictionary definition:
In English, the word "unit" has a specific meaning that goes beyond a simple element or component. In many real-world contexts, a unit refers to a self-contained, fully operational entity made up of multiple parts that work together toward a single purpose.
This is exactly what an Optimization Unit is in Edge Mining: it brings together an Energy System, a Mining System, a Policy, notifiers, and other components into a single, operational configuration. It is the top-level concept — the point where everything converges and the system becomes actionable.
For this reason, "Units" as a UI label is not generic or vague. It carries a precise meaning: a complete, self-contained configuration that unifies all the other elements of the system.
riccardoaran commentedon Apr 9, 2026
To conclude, this is my proposed terminology for the UI, and specifically for the sidebar:
markoceri commentedon Apr 10, 2026
What about External Services? Should we keep that name or change it to "Connectors" or something else?
sebailfico commentedon Apr 11, 2026
I like this new terminology a lot, I just have a doubt on the term "Units" because, if I put myself into a new user's shoes, I wouldn't grasp the meaning, but at the same time I think it's better to change the term "Optimization Unit" because it isn't clear in the same way.
As the "Unit" acts like an aggregate of the various entities, there is an implicit logic hierarchy between the unit and it's component, which may be reflected somehow in the sidebar.
Right now the most useful suggestion that comes to my mind would be to have the various entities like Energy, Policies, Miners to be child of the menu entry "Units". Or otherwise to have a new Units views with the various section, each section having the possibility to add or remove the various entities, which will be displayed as cards.
In this way, the Unit page would be a full overview of the actual Unit, instead of it being fragmented over multiple views.
Doing so, the UI/UX would reflect 1:1 the hierarchical relation between the entities and their container.
Also, now that we display entities as "cards", we could fit them more easily into a single page rather than the old ugly tables.
I'm aware that this suggestion is very messy, wide and could bring to a redesign of the UI, but I think it's worth sharing.
sebailfico commentedon Apr 11, 2026
I don't have a preference over this.
Connectors sounds better but it's a bit more abstract while Eternal services sounds clearer to me.
riccardoaran commentedon Apr 20, 2026
I love "connectors", I just didnt want to change the name drastically.
riccardoaran commentedon Apr 20, 2026
@sebailfico
I really like your proposal and I think your reasoning is absolutelylogical, especially the idea of reflecting the hierarchy between Units and their components directly in the UI.
For the 0.1.0 milestone my suggestion would be to keep all the sidebar entries on the same level (as peers).
Once we have some real usage and feedback, we can better understand how people actually navigate the app and then explore a redesign along the lines you’re suggesting, with Units acting more explicitly as a container view for Energy, Mining, Policies, etc.