Posts made by Hein-Jan

Hein-Jan

Mykle1

Thanks for your reply and confirming that it is a time-zone issues.
Instead of messing around with the code, I think I will simply off-set my event deadline time.
That way I am at least robust against updates.
Thanks for the work with the CET link.

Hein-Jan

Hein-Jan

@Mykle1

It feels like the timer is not indicating the correct time. It is set for 09:00:00. Current time is 21:40. Count down says we still have 17 hrs and 19 minutes to go. I think it should be 11 hrs and 21 minutes.
I am on Central European time. Could that be a contributing factor? Does the module vector in time-zone influences?

Hein-Jan

Hein-Jan

@AxLed

Sorry it took me some time to reply. Holidays and such.

In reply to your suggestions:
1st idea: Haven’t tried, I went a different route, see underneath.
2nd idea: had tried i before; commands via the URL worked.

It decided to go another route.
Instead of using MMM-ModuleScheduler I have opted to use Cron to do the MONITORON and MONITOROFF commands.
As I was only having trouble at the MONITORON command I first tried this in Cron.
To my surpise I now had a mirror in the morning but not in the evening.
It turned out that I was sending 1 MONITOROFF with Cron (after the nightly reboot).
Actually I am not using MONITORON and MONITOROFF in Cron but vcgencmd display_power 1 and vcgencmd display_power 0.
After the vcgencmd display_power 0 I was able to use Cron to turn the monitor back on with vcgencmd display_power 1
But after MONITOROFF I was not able to turn the monitor back on with vcgencmd display_power 1.
So MONITOROFF seems to be doing something strange in combination with the FakeKMS driver.

I think I read a similar conclusion in another post:
https://forum.magicmirror.builders/topic/8556/monitor-not-waking-up-from-sleep

So my work around for all this is Cron. And it is working. And I learned something about Cron.

Hope this may also help others who are struggling.

Hein-Jan

Hein-Jan

Silvor,

As far as I understand it, only the immediate next action is scheduled, once that action has been performed, the schedule will be studied and the following action will be scheduled.
So it makes sence that you see the first upcoming Monitor On, the first upcoming Monitor Off and the first upcoming Reboot.

By the way, are the time and date correct by the time mmm-mode scheduler is running?

Hein-Jan

@paulb

Is your device listed in “whitelist”, in your config.js?

Please check forum on whitelist issues.

Hein-Jan

Hein-Jan

@bhepler

As far as I can tell the

libGL error: MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information

Is due to the Open GL driver. I am using the Fake KMS and these are mine errors. I am not using NOAA.

Hein-Jan

Guys and gals,

I am at a loss here.

I have update to 2.4.1 and my mirror not longer automatically starts in the morning.

OK, so I have had my mirror for aprox. 18 months. In order to save a little on power consumption I am using a combination of MMM-Remote-Control and MMM-ModuleScheduler to turn my monitor on and off at certain times of the day. I am also using both modules to force a restart every night at 02:00 hr. This all worked well enough under previous MM versions.

I am using the fake KMS driver (dtoverlay=vc4-fkms-v3d), the full KMS-driver (dtoverlay=vc4-kms-v3d) is not compatible with the tvservice commands, that are being used in MONITORON and MONITOROFF.

This is a small part of my config (that did check out when I ran npm run config:check):

{
			module: 'MMM-ModuleScheduler',
			config: {
				notification_schedule: [
					//turn the monitor/screen on at 07:00 mon-fri
					{notification: 'REMOTE_ACTION', schedule: '00 7 * * 1-5', payload: {action: "MONITORON"}},
 					//turn the monitor/screen off at 08:15 mon-fri
					{notification: 'REMOTE_ACTION', schedule: '15 8 * * 1-5', payload: {action: "MONITOROFF"}},
					//turn the monitor/screen on at 17:30 mon-fri
					{notification: 'REMOTE_ACTION', schedule: '30 17 * * 1-5', payload: {action: "MONITORON"}},
 					//turn the monitor/screen off at 23:30 mon-fri
					{notification: 'REMOTE_ACTION', schedule: '30 23 * * 1-5', payload: {action: "MONITOROFF"}},
					//turn the monitor/screen on at 13:00 wed
					{notification: 'REMOTE_ACTION', schedule: '00 13 * * 3', payload: {action: "MONITORON"}},
					//turn the monitor/screen on at 10:00 Fri
					{notification: 'REMOTE_ACTION', schedule: '00 10 * * 5', payload: {action: "MONITORON"}},
					//turn the monitor/screen on at 09:00 sat
					{notification: 'REMOTE_ACTION', schedule: '00 9 * * 6', payload: {action: "MONITORON"}},
					//turn the monitor/screen off at 23:59 sat
					{notification: 'REMOTE_ACTION', schedule: '59 23 * * 6', payload: {action: "MONITOROFF"}},
					//turn the monitor/screen on at 09:00 sun
					{notification: 'REMOTE_ACTION', schedule: '00 9 * * 0', payload: {action: "MONITORON"}},
					//turn the monitor/screen off at 23:00 sun
					{notification: 'REMOTE_ACTION', schedule: '00 23 * * 0', payload: {action: "MONITOROFF"}},
					// restart the Pi at 02:00 every day
					{notification: 'REMOTE_ACTION', schedule: '00 02 * * *', payload: {action: "REBOOT"}},
					// turn monitor off after RESTART
					{notification: 'REMOTE_ACTION', schedule: '07 02 * * *', payload: {action: "MONITOROFF"}},
				]
			}
		},

I can run the MONITORON MONITOROFF and REBOOT commands from the remote controle website, and they work.

But if I look at the log ( /home/pi/.pm2/logs/mm-out-0.log ) I find something strange:

[CALEXT] https://calendar.google.com/calendar/ical/ XXXXX group.calendar.google.com/private- XXXXX /basic.ics  >> 
{ state: 'fetched but no change',
  lastFetchedTime: '18-07-15 01:58:21',
  lastFetchedEvents: 20,
  lastFetchedOldEvents: 20,
  lastServedEvents: 40,
  error: null }
MMM-ModuleScheduler is sending SEND_NOTIFICATION to REMOTE_ACTION
MMM-ModuleScheduler will next send SEND_NOTIFICATION to REMOTE_ACTION at Mon Jul 16 2018 02:00:00 GMT+0200 (CEST) based on "00 02 * * *"*
[CALEXT] https://calendar.google.com/calendar/ical/ XXXXXXXX group.calendar.google.com/private- XXXXXXX /basic.ics  >> Fetch starts.
[CALEXT] https://calendar.google.com/calendar/ical/ XXXXXXXXX group.calendar.google.com/private- XXXXXXXXX /basic.ics  >> Fetch starts.
[CALEXT] https://calendar.google.com/calendar/ical/nl.dutch%23holiday%40group.v.calendar.google.com/public/basic.ics  >> Fetch starts.
[CALEXT] https://calendar.google.com/calendar/ical/nl.dutch%23holiday%40group.v.calendar.google.com/public/basic.ics  >> Fetch starts.
[CALEXT] https://calendar.google.com/calendar/ical/ XXXXXXX group.calendar.google.com/private- XXXXXXX /basic.ics  >> Fetch starts.
[CALEXT] https://calendar.google.com/calendar/ical/nl.dutch%23holiday%40group.v.calendar.google.com/public/basic.ics  >> 
{ state: 'fetched',
  lastFetchedTime: '18-07-15 02:00:37',
  lastFetchedEvents: 0,
  lastFetchedOldEvents: 0,
  lastServedEvents: 0,
  error: null }

A little before 02:00 hr Calender is Fetching info; at 02:00 MMM-ModuleScheduler sends a notification (I think it is the REBOOT ). At 02:00:37 Calender starts a new Fetch. This does not make sense, I was expecting to see something like:

> magicmirror@2.4.1 start /home/pi/MagicMirror
> sh run-start.sh

Starting MagicMirror: v2.4.1
Loading config ...
Loading module helpers ...

It looks like MM is not accepting commands from MMM-ModuleScheduler, but :

[CALEXT] https://calendar.google.com/calendar/ical/ XXXXXX group.calendar.google.com/private- XXXXXX /basic.ics  >> 
{ state: 'fetched but no change',
  lastFetchedTime: '18-07-14 23:58:21',
  lastFetchedEvents: 19,
  lastFetchedOldEvents: 19,
  lastServedEvents: 38,
  error: null }
MMM-ModuleScheduler is sending SEND_NOTIFICATION to REMOTE_ACTION
MMM-ModuleScheduler will next send SEND_NOTIFICATION to REMOTE_ACTION at Sat Jul 21 2018 23:59:00 GMT+0200 (CEST) based on "59 23 * * 6"****
Powering off HDMI

It seems to be working here.

Why can it Switch off (Monitor) automatically, but not Reboot or Switch on (Monitor) automatically?

Anyone?

Hein-Jan

Hein-Jan

@michmich

I seem to be running into some kind if trouble. My SD card failed, so I had to do a clean install. I decided to immediately go for the full KMS driver.
“$ tail /boot/config.txt | grep dtoverlay” results in “dtoverlay=vc4-kms-v3d”.

The CPU usage is alright, but “/home/pi/.pm2/logs/mm-error-o.log” states:

libGL error: MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information
MESA-LOADER: failed to retrieve device information

I am having trouble with the monitor. I am using MMM-Remote-Control.
“MONITOROFF” results in “/home/pi/.pm2/logs/mm-error-o.log”:

Powering off HDMI

“MONITORON” results in “/home/pi/.pm2/logs/mm-error-o.log”:

Powering on HDMI with preferred settings

[E] Failed to power on HDMI with preferred settings

{ Error: Command failed: tvservice --preferred && sudo chvt 6 && sudo chvt 7
[E] Failed to power on HDMI with preferred settings

    at ChildProcess.exithandler (child_process.js:217:12)
    at emitTwo (events.js:106:13)
    at ChildProcess.emit (events.js:194:7)
    at maybeClose (internal/child_process.js:899:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:226:5)
  killed: true,
  code: null,
  signal: 'SIGTERM',
  cmd: 'tvservice --preferred && sudo chvt 6 && sudo chvt 7' }
Powering off HDMI

I may be wrong but I feel this is related to the Full KMS driver.

Can anyone confirm? Does anyone have a solution?
I am way out of my depth here…

Hein-Jan

@gama

Look into issue:

https://forum.magicmirror.builders/topic/5071/mmm-calendarext-cant-get-the-calendar-to-show

It is a problem of Electron that has been downgraded.

The default calendar module has had some issues removed in the update, maybe it is now okay for you.

Hein-Jan

@Sean

If I read this right:

Changed

* Calender week is now handled with a variable translation in order to move number language specific.
* Reverted the Electron dependency back to 1.4.15 since newer version don’t seem to work on the Raspberry Pi very well.

MM has indeed downgraded…