@Rberry91 the file path doesn’t have <> in it that was just substitute thing here

I have to admit that a LLM makes very beautiful code. It doesn’t work yet, but it is beautiful. This is the first version created: https://github.com/Brtrnd/MMM-Photoprism I’ll spend some more time on it this evening. Once the first draft works I think i can imagine quite a few extra’s I would like to add.

@sdetweil Maybe I’m wrong, and I haven’t spent a lot of time trying to test it, but I think regular moment will grab the date in the local timezone based on what is set in the system. You can’t do as much with OTHER timezones in regular moment, but I think at least that works. Whereas the regular javascript date will pull the date and time in UTC. That said, I do use moment-timezone in my modules–though some of them I have taken over maintaining, and they used regular moment to some success.

@sdetweil said in LICENSE: on modules.magicmirror.builders shows @noassertion instead of MIT: click the hints for dev view bottom left hint link works … looks like problems on your side …

Hi @Jalibu, thanks for the typings. To be honest, it’s not the best possible integration. The MagicMirror repository includes a module-types.ts file, containing the most important types, which I extended a little to fit my needs. A deeper integration, like being able to get correct typings/autocompletion for the this object in functions, is not available. If I find myself using it more in the future, I may look into improving this. I want to share an little extension or may a solution for the problem quoted: import type { Config } from "../types/Config"; import type { State } from "../types/State"; interface FrontendModuleProperties extends Partial<Module.ModuleProperties<Config>> { state?: State; } Module.register<Config>("MMM-XX", { defaults: { x: 29, y: "abc", }, getStyles() { return ["z.css"]; }, <...> getTemplateData() { return { config: this.config, value: this.state?.value, }; }, <...> socketNotificationReceived(notificationIdentifier: string, payload: State) { if (notificationIdentifier === `ABC-${this.identifier}`) { const lastValue = this.state?.value; // <-- Here lastValue got correct type automatically <...> this.state = payload; } }, } as FrontendModuleProperties);

@mumblebaj , @karsten13 and @sdetweil , thank you really for your help with this matter. I will test tomorrow and hope all this story will help other user in the future to profit from all your great job!

@sdetweil I’d rather have late and working consistently than early and missed because of lag. I suspect most people boot their mirror at most once a day, so waiting an extra 30 seconds for the module to show content doesn’t seem like that big of a deal. But I’ll try DOM_OBJECTS_CREATED.

@Xx_Codeur_xX You could have a look at some of the modules that already does this. They get the weather from the default weather module, no need to redo this as it is already available. See either of the below. https://github.com/fruestueck/MMM-WeatherDependentClothes or https://github.com/Lavve/MMM-WeatherOutfit/tree/main

@karsten13 – Yes, that’s what I figured. The problem from the provider’s perspective would be how to both give access to legitimate subscribers while limiting access to others. The only solution that springs to mind would be to authenticate the user when they query the server, but for something like this where all the users’ computers might each be coming for content several times each day - it begins to be a lot of computing overhead.

@newbi ok.

@raspberrypi9 did you get this working?

@raspberrypi9 my pleasure, And actually DOM_OBJECTS_CREATED means YOUR module’s content has been placed in the DOM the first time And DOM_OBJECTS_UPDATED is each time after that Because updateDom() is asynchronous now If you ever tried to document.getElementByID after getDom(), but it returned null. Then you needed to wait for one of those notifications

@raspberrypi9 i deleted the duplicate topic

@raspberrypi9 did you figure this out?

@sdetweil did you make any progress?

@68jeeper yes! Sorry for the delayed response, I didn’t receive any notifications that you tagged me in this post. My solution was to use (https://github.com/JanLoebel/mmm-touchgestures). Hammer.js seems to be the difference and why this one works. The documentation was challenging for me ti follow but I was able to get it working through trial and error. My config look like this for MMM-touchgestures { module: 'mmm-touchgestures', config: { gestures: { "swipe": { enabled: true, threshold: 50 } }, actions: { "swiperight" : function() { return "PAGE_INCREMENT"; }, "swipeleft" : function() { return "PAGE_DECREMENT"; }, "swipeup" : function() { console.log("Triggered swipeup"); }, "swipedown" : function() { console.log("Triggered swipedown"); }, }, } },

for MagicMirror purposes, is there a preferred style to be used for modules? @kayakbabe I agree with Sam, but here’s a more detailed answer anyway: This depends on where you are. In some modules there are no rules for this - there and in your own modules it is, as Sam says, up to you. However, to avoid poor code style, such as spaghetti code and inconsistently formatted code, which not only make maintenance and further development more difficult, but also affect team collaboration, many projects use static code analysis tools such as prettier and ESLint for checking code quality. In the MagicMirror core (and with this in the default modules), we use the ESLint object-shorthand rule (see https://archive.eslint.org/docs/rules/object-shorthand) to ensure that only the shorthand version is used.

@raspberrypi9 google is your friend [image: 1740971825398-img_0817.png]