Seperate Config for Web Access

cweinhofer

I’d like to propose some functionality for people like me who want to display their MM info on two (or more) displays with slightly different configurations on each.

I’m not a programmer, but I’ve tried to devise a solution that will allow for the functionality at a basic level, but at the same time should be comparatively simple to program and backward compatible. I’ll give more of my rationale after the suggestion, so here goes:

Add an integer option named displays as the first option in the config file. The default value for this would be “1” in which case the config file would work as it does now. If the value is “2” or greater, two additional options would become available.
Under port, port would become an alias for port-display1 (or vise-versa) and additional options named port-display2, port-display3, etc. would be required, matching the number of displays. This will allow the alternate configurations to be accessed using the built-in webserver with an alternate port number.
The same would occur under within each module under position, i.e. position becomes an alias for position-display1 and then add position-display2, position-display3, etc.
Add a value of hidden to the list of possible values for position. If the value is hidden, the module is not shown on that display.
Add a CSS class to each “display” so that the content can be styled individually. e.g.

.display2 .clock .time {
     font-size: 72px;
}

Here is my rationale in the above proposal:

Making the current option name an alias for “…display1” allows for backward compatibility, so no one’s install gets broken.
If people are wanting multiple configs, they are likely using the built-in webserver to display these on other machines. The display on the local machine would always use the first config (i.e. …display1”).
For most modules the same configuration would be acceptable for all displays. The main I’m guessing people would want to change is where and/or whether the module appears. Styling changes could then be accomplished through the additional CSS class.
I know this way of doing it somewhat limits what can be done, but my guess is that most people who could benefit from this function would be willing to trade reduced customizability for getting the functionality actually added.

sdetweil

@cweinhofer you can run another (server) instance from the same folder w a different config using the MM_CONFIG_FILE environment variable

u can set the port that way too
MMM_PORT

and u can use a different custom.css in each config file… with the customCss property
which is the path/name in the mm folder of the css file to use for this instance

so you can get what you want now, different views by port number

sdetweil

@cweinhofer and while more tedious setup you can enable different views on the same port

see
https://forum.magicmirror.builders/topic/17190/seperate-config-for-web-access/4?_=1663845770037

truck hint , modules can be loaded, but start hidden

cweinhofer

Thanks, but my objective in suggesting this is not simply to get different configs at different ports. That’s necessary, of course, but as you mention it can already be accomplished with multiple instances. (And for reference, this is what I’m currently doing.)

I’ve found the multiple instance method to have a few downsides that compound as the number of instances grows. I’m currently running two instances – where the difficulties are a pain but manageable. But I was thinking of adding some extra displays that would take me four instances – where the difficulties would become somewhat untenable.

multiple instances means multiple API calls and/or HTTP POST requests from my sensors. In the case of the HTTP POST requests, I have to use CNAMEs on my router to make my MM machine look like multiple machines and then program the sensor to run the same HTTP POST routine multiple times for each “machine”. Thankfully my router and sensor firmwares (OpenWRT and Arduino) allow for this, but others would not.
multiple instances means that I have to maintain multiple config and CSS files. In my case 90% of the config and CSS files are the same (formatting settings, API credentials, sensor data display parameters, etc.) so if I make changes in that 90%, I have to make notes (or use a file compare utility) to make sure the same changes are copied over to all the instances.

I guess my thought here is that many people have a pile of old phones and tablets sitting around collecting dust and adding functionality like this would make it very easy to repurpose those as useful extensions of their MagicMirror.

sdetweil

@cweinhofer each instance client causes request to data providers (even thru node helpers). almost NO module shares data with other instances
(I made concerted efforts in my MyCovid19 module to do that… not easy) ( I think one of the third party climacell weather modules does this)

so same or different port doesn’t help here. same or different instance doesn’t help, same or different server.

all the same.

for the 4 or 5 of you that might want to do this, you can create scripts to merge common elements, use source repositories and other approaches to minimizing the work of config construction, without burdening the core support with out of scope function.

this is a composable information display panel with a single view.

as this is open source, you are welcome to take the repo and do what you suggest.

to have your idea considered more specifically, you should open an issue on the GitHub repo to engage the core team.

nothing said here will affect this kind of change