Architecture suggestion: new “data sources” category

[dathbe]

This would be a larger architectural change for some later major release, but I’m curious to get people’s thoughts on splitting the current modules into two different sections: one for data sources and one for display modules.

The specific issue I’m trying to resolve is minimizing API calls. I have three weather modules (one for alerts, one for a rain map, and one for current weather and forecast). All three draw from OpenWeatherMap API, but none use the same notification name/structure. This results in 3x the API calls, when one should be sufficient.

I think an elegant (though course-changing) solution would be to have a set of data sources that would grab data and present them in notifications, so that the display modules can (should) draw from one or more to present the information in various formats.

This would also help users weed through the modules. Users could look for data sources they’re interested in and then be presented with a narrower list of modules that can display that data source.

And it would help developers by not making them recreate the wheel when a method for collecting the data they want to use.

Probably a pipe dream, but it was a thought I had.

[MarcLandis]

Like an hour ago I was thinking about the exact same approach and then I found this request. I absolutly support this.

[bugsounet]

maybe an idea,

• Define needs from other modules
• Format an object with data received from the weathers providers used with weather default module (need to create an MagicMirror weather object with max informations when calling weather API)
• send data in MagicMirror defined format with notification

---> modules can use it

We have coded +/- the same thing with calendar default module

[khassel]

the default weather module already sends notifications, I'm using the default weather module as data provider here.

[sdetweil]

calendar and weather broadcast their data what else is there?

[dathbe]

calendar and weather broadcast their data what else is there?

1. There are far more sources of data than calendar and weather.
2. There are far more sources of calendar and weather data than what is broadcast by the default calendar & weather modules.
3. Without explicit reference to the calendar and weather modules being data providers, with documentation of what they provide and in what format, other devs have to reverse engineer what those modules (or any other modules) are doing to repurpose it.

There are just two very different things that modules are doing: grabbing data; and displaying it. Various modules and devs have strengths in one or the other.

[sdetweil]

alert has no data compliments data is visible in config updatenotification no useful data

[dathbe]

The default modules are not the only sources of data.

[sdetweil]

oh, you want US to build and support a random storage database

[sdetweil]

@bugsounet weather does all that already

[dathbe]

oh, you want US to build and support a random storage database

No, but thanks for the sarcasm.

[sdetweil]

@dathbe what other modules provide data that is duplicated by others?

ive been here 7 years and don't see a single other module content consumed by others. plenty of time to become a provider

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[aaronaxvig]

First time I have looked at this issue is today, but I have been rolling around the idea of something like this for images for a couple months now. If you look at various image display modules, they support various and random images sources like Google Photos, local folder, OneDrive, etc. So you have to get lucky that the display module you want happens to support the source you want.

There should be modules like MMM-ImagesOneDrive, MMM-ImagesGooglePhotos, MMM-ImagesWikipediaCities, MMM-ImagesNextcloud (this is the one I want haha) etc. These would "broadcast" metadata about the images, or perhaps the images themselves depending on memory/scalability, same as calendar module. And then there should be display modules like MMM-ImageBackground, MMM-ImageCarousel, etc. that focus on displaying the images, possibly subtitles or whatever.

"Someday" I'll get around to building it myself. I think it is a good way of doing it, except for the reverse engineering sort of thing mentioned above.

[sdetweil]

well, really one module with different sources MMM-Images source:OneDrive,GooglePhotos, WikipediaCities, Nextcloud , ... you can have different subfiles to call to 'get the list'/and 'image'

and for that source whatever credentialing is required

98% of the module is identical , just a tiny bit is different for interfacing to the source

like we do with weather I used this approach in my second module (which no longer works due to electron changes), but I get images from multiple sources, each has a provider file, with 2 apis, getlist(), getnextImage()

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.