Fixes https://github.com/MichMich/MagicMirror/issues/3182
Fixed issue with probability of precipitation not showing up on hourly
or daily forecast
---------
Co-authored-by: veeck <michael.veeck@nebenan.de>
Hello,
This pull request allows you to add a class to the tr of the event
sought in customEvents. You must enter the class with the "eventClass"
option.
---------
Co-authored-by: TeddyStarinvest <teddy.payet@starinvest.com>
related to #2649
I was able to move to internal fetch and all tests seems fine so far.
But we have one problem with the calendar module. In the docs we have
several authentication methods and one of them is `digest`. For this we
used `digest-fetch` which needs `node-fetch` (this is not so clear from
code but I was not able to get it working).
So we have 3 options:
- remove `digest` as authentication method for calendar module (this is
what this PR does at the moment)
- find an alternative npm package or implement the digest stuff
ourselves
- use `digest-fetch` and `node-fetch` for calendar module (so they would
remain as dependencies in `package.json`)
Opinions? @KristjanESPERANTO @rejas @sdetweil @MichMich
Update calendarfetcherutils.js to force recurrence date time to be the
same as event datetime
I found an issue with one of my calendars displaying the wrong time for
certain recurring events. Each event was set up by someone in a
different timezone (Central European) than my own (Eastern US). I traced
the issue back to the `Rrule.between()` method generating odd time
portions under certain circumstances.
The fix I found was to set the UTC time portion of the recurrence
datetime to be the same as the UTC time portion of the event start date.
This resolved the issues with the maladjusted event times, and had no
effect on other event times. While there may be edge cases that are
affected, I have been unable to locate any.
---------
Co-authored-by: Veeck <github@veeck.de>
Fixes#3126
Added the option `allowOverrideNotification` to `weather.js`. This
allows the module to receive the `CURRENT_WEATHER_OVERRIDE`
notification. The expected payload for this notification is a
full/partial `weatherObject` that is used to supplement/replace the
existing `weatherObject` returned by whichever weather provider is in
use.
No visual changes.
First time contributing - let me know if I've missed something
🙂
---------
Co-authored-by: veeck <michael.veeck@nebenan.de>
fixes#3138 just in case #3137 doesnt get worked on until the next
release
- inc fetchInterval for sample calender
- add fetchInterval config per calendar
... but e.g. a version tag
fixes#3130
This happens e.g. in my docker image where I use the version tag to get
the mm sources.
With this PR the error message is avoided and there will be never an
updatenotification when using a tag. This is o.k. because a tag should
never be moved.
Hi,
Like some default modules, I propose to send an `UPDATES` notification
in an array with the git information of these modules
This allows developers to create their own auto-update system (which
I've been using in my case since 3 years, with automatic things)
Of course, for security reasons `MagicMirror` is excluded
---------
Co-authored-by: bugsounet <bugsounet@bugsounet.fr>
This pr adds (config.js toggleable) showUV_Index to the hourly and
current weather modules, with right now only openmeteo configured to
supply the data. Other providers could have support too by adding
`uv_index` to current and hourly.
For example the current weather looks like
positioned after sunset in the top row.
The following "hacks" are included and could be fixed to make it
cleaner, but the functionality is wanted and it works without problem.
- To hide entries where the UV Index is 0 i added an if statement to the
`hourly.njk` which is not how precipitation is handled.
The following are minor things that might not need fixing:
- The forecast option does not have UV support. This might not be
relevant since UV changes throughout the day but i tried to implement a
"max_UV" to openmeteo.js, but am not confident enough in JS to
accomplish that.
- The UV Icon is wi-hot and manually added to the `.njk`'s. This could
be made changeable by a config but does not seem relevant since wi-hot
is not used by anything else as far as i can tell.
---------
Co-authored-by: veeck <michael@veeck.de>
Fix for today's probability-of-precipitation weather module's envcanada
provider.
Without which, requesting `showPrecipitationProbability` causes
"undefined" to be shown.
Consistent with method used elsewhere in the file:
abe5c08a52/modules/default/weather/providers/envcanada.js (L395-L399)
Adding date to the clock module when displayType is "analog" and
"showDate" is true. The setting in analogShowDate is respected.
Fixes#3100
---------
Co-authored-by: Michael Teeuw <michael@xonaymedia.nl>
Co-authored-by: Veeck <github@veeck.de>
Fixes#3095.
Param `hideOngoing` is by default set to `false`, but the event
filtering handles `full day` & `non-full day` events inconsistently. For
`non-full day` _ongoing_ and _upcoming_ events are returned, while for
`full day` only _upcoming_ events where returned.
Due to the size of the commit there is no need for a long explanation:
Openmeteo supports precipitation probability in api, but the weather
provider .js had no support for it. After adding 4 lines it works as
expected. This should have no consequences on other files but improves
usability for (imo) the best weather provider.
---------
Co-authored-by: veeck <michael@veeck.de>
While waiting for the easterbunny I cleaned up some bad coding practice
:-)
Very open for comments especially regarding the places I commented
myself...
---------
Co-authored-by: veeck <michael@veeck.de>
Refactored some methods in calendar module:
- move methods into own file
- dont call shorten method from titelTransform because why? just call
them after each other.
- added tests for util methods
- cleaned up other tests
---------
Co-authored-by: veeck <michael@veeck.de>
Updated sunrise/sunset times to display user-requested timezone rather
than system timezone.
Note: rebase of #3069 against develop rather than master
Co-authored-by: Veeck <github@veeck.de>
While looking at https://github.com/MichMich/MagicMirror/pull/3070 I
noticed that the weather and clock module do some formatTime stuff, so
why not use a common function for that?
---------
Co-authored-by: veeck <michael@veeck.de>
Fixes#3056
One question here would be if the default for this new option should be
true or false.
True: keeps the current behaviour, nobody needs to change his config if
they rely on this option
False: keeps the clock notifications quiet, doesnt waste time/resources,
keeps the noise low
Maybe the original author @cybex-dev can weigh in on this, and why he
added this notification.
---------
Co-authored-by: veeck <michael@veeck.de>
- order (external first)
- remove superfluous file extensions
- new line after imports
- deconstruct (only one time (in `check_config.js`))
- fix path (only one time (in `global-setup.js`))
We have used it inconsistently till now. Template literals are more
modern and easier to maintain in my opinion.
Because that's a large amount of changes, here's a way to reproduce it:
I added the rule `"prefer-template": "error"` to the `.eslintrc.json`
and did an autofix. Since this caused a new problem in line 409 of
`newsfeed.js`, I reversed it in that line and also removed the rule from
the eslint config file.
The rule is described here:
https://eslint.org/docs/latest/rules/prefer-template
Note: I've played around with some other linter rules as well, and some
seem to point to some specific, non-cosmetic, issues. But before I dive
even deeper and then introduce even bigger and hardly understandable
changes at once, I thought I'd start with this simple cosmetic rule.
Fixes [#3064](https://github.com/MichMich/MagicMirror/issues/3064)
- Fixes default alert module nunjucks templates to render HTML by
default unless 'titleType' and 'messageType' are set to 'text' in the
payload data
e.g.
Display Text:
`this.sendNotification('SHOW_ALERT', {type: "notification", title:
"<u>YoLink LeakSensor</u>", titleType: "text", message: "<b>" +
deviceName + "</b> reported an alarm that needs attention.",
messageType: "text"});`
Display HTML:
`this.sendNotification('SHOW_ALERT', {type: "notification", title:
"<u>YoLink LeakSensor</u>", message: "<b>" + deviceName + "</b> reported
an alarm that needs attention."});`
Hi,
want to include a birthday calendar to my mirror which shows upcoming
birthdays and as a reminder birthdays of the last two days.
I used
[MMM-CalendarExt2](https://github.com/MMM-CalendarExt2/MMM-CalendarExt2)
for this job in the past but the module is not supported any more and
very complicated to configure.
I managed to style the default calendar module to my needs but what i am
missing is to display already past events within a configurable time
range.
I included the translations of "YESTERDAY" and "DAYBEFOREYESTERDAY" to
all translation files and modified the code to accept a new option
`pastDaysCount` which controls of how many days past events should be
displayed.
---------
Co-authored-by: Veeck <github@veeck.de>
Percentage should be always rounded so that we dont get something like
"47.0000000001 %"
Some small typo and naming fixes also while I am here
---------
Co-authored-by: veeck <michael@veeck.de>
actually add it to the tanslation list
and also add the alert translations from
https://github.com/MichMich/MagicMirror/pull/3029 since the OP didnt
seem to work on it (yet)
---------
Co-authored-by: veeck <michael@veeck.de>
Co-authored-by: Suthep Yonphimai <tomzt@users.noreply.github.com>
1. Update `stylelint` dependencies
- As of stylelint v15, we do not need `stylelint-config-prettier`
anymore:
https://github.com/prettier/stylelint-config-prettier/releases/tag/v9.0.5
2. Switch to `stylelint-config-standard`:
`stylelint-prettier/recommended` has not been updated for a long time
and still needs the old `stylelint-config-prettier`
3. Handle new `stylelint` issues
They weren't applied to wrong classnames, this PR fixes that and also
expands the weather util tests
---------
Co-authored-by: veeck <michael@veeck.de>
This commit adds several QOL features and adjustments to the calendar
module including:
- **New Options**
- ``coloredText``: ``(default: false)`` Determines if you want your
entry text to be colored based on the calendar's color
- ``coloredBorder``: ``(default: false)`` Determines if you want entry
borders to be colored based on the calendar's color
- ``coloredSymbol``: ``(default: false)`` Determines if you want entry
symbols to be colored based on the calendar's color
- ``coloredBackground``: ``(default: false)`` Determines if you want
entry backgrounds to be colored based on the calendar's color
> These new colored options allows for more out-of-box styling options
for the calendar module. With this the ``coloredSymbolOnly`` option has
been removed due to redundancy
- ``limitDaysNeverSkip``: ``(default: false)`` show every event for
every day regardless of if the day only has a single full day event
- ``flipDateHeaderTitle``: ``(default: false)`` determines if the title
for the date header in the ``dateheaders`` time format should align to
the left ``[eg: false]`` or right ``[eg: true]``
- **Layout Changes**
- ``dateheader`` is now a class avaliable for date headers in the
``dateheaders`` time format.
- Event entries have been better *container-ized* for better styling
(using the ``event-container`` class)
- ``repeatingCountTitle`` now has a seperator between the ``yearDiff``
and ``repeatingCountTitle``
- ``endDate`` in ``dateheaders`` now capitalizes it's first letter
Fixes#2953
This is an attempt to fix the issue with precipitation amount and
percentage mixup. I have created a separate
`precipitationPercentage`-variable where the probability of rain can be
stored.
The config options now has the old `showPrecipitationAmount` in addition
to a new setting: `showPrecipitationProbability` (shows the likelihood
of rain).
<details>
<summary>Examples</summary>
### Yr
I tested the Yr weather provider for a Norwegian city Bergen that has a
lot of rain. I have removed properties that are irrelevant for this demo
from the config-samples below.
Config:
```js
{
module: "weather",
config: {
weatherProvider: "yr",
type: "current",
showPrecipitationAmount: true,
showPrecipitationProbability: true
}
},
{
module: "weather",
config: {
weatherProvider: "yr",
type: "hourly",
showPrecipitationAmount: true,
showPrecipitationProbability: true
}
},
{
module: "weather",
config: {
weatherProvider: "yr",
type: "daily",
showPrecipitationAmount: true,
showPrecipitationProbability: true
}
}
```
Result:<br/>
<img width="444" alt="screenshot"
src="https://user-images.githubusercontent.com/34011212/216775423-4e37345c-f915-47e5-8551-7c544ebd24b1.png">
</details>
---------
Co-authored-by: Magnus Marthinsen <magmar@online.no>
Co-authored-by: Veeck <github@veeck.de>
see discussion here:
https://github.com/MichMich/MagicMirror/pull/2991#issuecomment-1376372720
I still see a need for updating `master` in special cases (e.g. correct
errors in README.md which would otherwise be present up to 3 month until
next release) so with this PR **only for MagicMirror repo** and **only
for `master` branch** updatenotifications are only triggered if at least
one of the new commits has a tag.
May @MichMich must decide if this is wanted.
Co-authored-by: Veeck <github@veeck.de>
This simple change allows to use your own templates (under "templates"
directory). The parameter `templateName` is optional (ignored on falsy
value - undefined, null, empty string, etc.) and independent of `type`.
Co-authored-by: Veeck <github@veeck.de>
This keeps relative dates accurate when the calendar's fetch frequency
is much larger than a minute.
As fetching incurs network traffic and load on servers and most
calendars don't update that often, simply refreshing locally is enough.
When using relative for today's events, dates will show as "in X
minutes" or "ends in X minutes" for events within an hour and this goes
out of date quickly. It's weird to see that the time is, say, 16:30 and
an event that you know ends at 16:45 is shown to "ends in 23 minutes"
because that's when the last fetch happened.
Please forgive me if there's style issue, I don't have npm set up on my
machine to run the formatter.
Fixes#3019
The previous implementation had the arrow pointing in to the wind. When
the wind blows from the north (0 degrees), the arrow should point
straight down. In other words, no rotation of the arrow-down symbol.
When the wind blows from the south (180 degrees), the arrow should point
straight up (I.e. the arrow down symbol rotated 180 degrees).
Co-authored-by: Magnus Marthinsen <magmar@online.no>
