Just been reading about the Google mediapipe libs that supposedly provide reasonably lite gesture recognition and wondered if anybody has or is intending implementing a webcam method?

@andoramb I don’t think there is but https://github.com/paviro/MMM-PIR-Sensor prob could be hacked with a few changes.

xrandr --output <outputname> --brightness 0.8 would be part of the script ?

Guess also if you have a webcam it should be possible to create a lux level also.

Same in as they both use the same terrible outmoded methods that is essentially a copy of zram-conf-05.deb.

Since kernel 3.15 zram has been multi-stream and partitioning by core just makes smaller swaps with smaller single page write ability for absolutely no reason.
Also makes no check that any previous zram utils maybe in operation and overwrites.
Ignores the important mem_limit property for sys_admins and completely ignores the hot_plug and remove methods.

I have no idea why that bad script has been copied and emulated so much, but yeah the above are very much the same as zram-conf-05.deb.

I suggest you have a look at https://github.com/StuartIanNaylor/zram-config as it combines many functions that are beneficial for MagicMirror and has a better implementation of zram for quite a few reasons.
Uses /etc/ztab so if you wish you can set up as many zswaps, zdir and a zlog if you wish.
Zlog creates a zram directory which is the upper in a OverlayFS file systems so only on write is a file copied up. It also uses the olddir directive of logrotate so oldlogs are shipped to persistent.
Provides negligible flash wear and an extremely small Zram memory footprint.
Zdir is the same as zlog without the logrotate directives where the MagicMirror directory is loaded via a OverlayFS mount with the upper mounted on zram.
Due to the copyup of COW only files that are write accessed use upper so again the whole MagicMirror dir can be provided with zero SD writes in an extremely small memory footprint.
You can make as many Zdir as you need.
Zswap does actually use the kernel doc methods of hot_plug and hot_remove for zram devices and will work with other zram services.
Also includes the important mem-Limit for sysadmin and Zswap is multi-stream and there is little point making swaps per core but you can make as many as you like.
Linux swapiness and page-cache settings are also based the assumption of HDD like swap and zram is mem not disk so swapiness needs to be increased to 80-100 and page-cache set to 0 for single pages to help cut latency as the default of 3 = caches of 8 pages for disk based caching.
None of the scripts ever seem to provide the tuneables to actually utilise zram performance and again you can set both in the ztab as you set up your swap.

Hopefully the likes of the above will actually read the kernel docs for zram https://www.kernel.org/doc/Documentation/blockdev/zram.txt before they just copy and paste a bad Ubuntu script again.

Not really sure how zram will in anyway give you smooth youtube/video playback though… ? But if its caching locally then yes.
But yeah you can get near memcpy speed with compression rations of up 3:1 or even use deflate or ztstd which are slower and prob not for swap but for text such as logs or much of the data format that nodejs uses the compression can be much higher than the performance base of LZO/4.

https://github.com/StuartIanNaylor/zram-config

pi@raspberrypi:~ $ zramctl
NAME       ALGORITHM DISKSIZE  DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lz4           1.2G    4K   76B    4K       4 [SWAP]
/dev/zram1 lz4           150M 16.3M 25.1K  208K       4 /opt/zram/zram1
/dev/zram2 lz4            60M  7.5M  1.2M  1.7M       4 /opt/zram/zram2

pi@raspberrypi:~ $ df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/root       14803620 2558152  11611220  19% /
devtmpfs          470116       0    470116   0% /dev
tmpfs             474724  223868    250856  48% /dev/shm
tmpfs             474724   12284    462440   3% /run
tmpfs               5120       4      5116   1% /run/lock
tmpfs             474724       0    474724   0% /sys/fs/cgroup
/dev/mmcblk0p1     44220   22390     21831  51% /boot
/dev/zram1        132384     280    121352   1% /opt/zram/zram1
overlay1          132384     280    121352   1% /home/pi/MagicMirror
/dev/zram2         55408    3460     47648   7% /opt/zram/zram2
overlay2           55408    3460     47648   7% /var/log
tmpfs              94944       0     94944   0% /run/user/1000

cat /etc/ztab
# swap  alg     mem_limit       disk_size       swap_priority   page-cluster    swappiness
swap    lz4     400M            1200M           75              0               90

# dir   alg     mem_limit       disk_size       target_dir              bind_dir
dir     lz4     50M             150M            /home/pi/MagicMirror    /magicmirror.bind

# log   alg     mem_limit       disk_size       target_dir              bind_dir                oldlog_dir
log     lz4     20M             60M             /var/log                /log.bind               /oldlog

pi@raspberrypi:~ $ free -h
              total        used        free      shared  buff/cache   available
Mem:           927M        206M        184M        233M        535M        434M
Swap:          1.3G          0B        1.3G

pi@raspberrypi:~ $ swapon
NAME       TYPE      SIZE USED PRIO
/dev/zram0 partition 1.2G   0B   75
/var/swap  file      100M   0B   -2

pi@raspberrypi:/opt/zram $ ls
log.bind  magicmirror.bind  oldlog  zram1  zram2

pi@raspberrypi:/opt/zram $ top
top - 23:18:21 up  1:28,  2 users,  load average: 0.31, 0.29, 0.29
Tasks: 114 total,   1 running,  68 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.9 us,  0.1 sy,  0.0 ni, 98.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :   949448 total,   153464 free,   223452 used,   572532 buff/cache
KiB Swap:  1331192 total,  1331192 free,        0 used.   412052 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 1215 pi        20   0  600844 325968 287276 S   5.3 34.3   8:09.51 chromium-browse
 2536 pi        20   0    8104   3204   2728 R   1.6  0.3   0:00.11 top
  970 pi        20   0  775108 156128 112876 S   1.0 16.4  11:17.06 chromium-browse
 1611 pi        20   0   11656   3772   3056 S   0.3  0.4   0:00.30 sshd
    1 root      20   0   27072   5964   4824 S   0.0  0.6   0:02.51 systemd
    2 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kthreadd
    4 root       0 -20       0      0      0 I   0.0  0.0   0:00.00 kworker/0:0H
    6 root       0 -20       0      0      0 I   0.0  0.0   0:00.00 mm_percpu_wq
    7 root      20   0       0      0      0 S   0.0  0.0   0:00.24 ksoftirqd/0
    8 root      20   0       0      0      0 I   0.0  0.0   0:00.87 rcu_sched
    9 root      20   0       0      0      0 I   0.0  0.0   0:00.00 rcu_bh

Don’t know if you know how generally stinky the ubuntu zram-conf-05.deb is but take it from me it contains high notes of cheese.

I think I have completed at least a zram-conf that in name allows you to configure zram which might be useful for the magicmirror folder as mounting a zram drive at /magicmirror will cut sd blockwear to somewhere to nothing to extremely minimal whilst running at near ram speed.

All the info is at https://github.com/StuartIanNaylor/zram-config

sudo apt-get install git
git clone https://github.com/StuartIanNaylor/zram-config
cd zram-config
sudo sh install.sh

Will get you up and running but it all fairly easy runs from a ztab file in /etc where you can set as many drives or swaps as you wish even logs.

If anyone fancies giving it a try please do as needing some testers but seem to be working fine.

I should of mentioned these things, doh!

https://www.aliexpress.com/item/Original-New-Broadlink-RM-Mini3-Black-Bean-Smart-Home-Universal-Intelligent-WiFi-IR-4G-Wireless-Remote/32647630434.html?spm=2114.search0104.3.23.2fe91284aQbOSk&ws_ab_test=searchweb0_0,searchweb201602_4_10065_10068_10130_10547_319_317_10548_10696_10192_10190_453_10084_454_10083_10618_10307_10820_10301_10821_10303_537_536_10902_10059_10884_10887_321_322_10103,searchweb201603_16,ppcSwitch_0&algo_expid=28da5b57-2352-4519-88f0-0f130177d914-3&algo_pvid=28da5b57-2352-4519-88f0-0f130177d914&transAbTest=ae803_3

But basically a Pi with an IR LED

Yeah that will be amazing will have to check it out.

Its back must of wanted me to have a coffee?!

Is there a prob with current weather?

weather forecast is OK but for some reason current weather seems to be doing that Loading… today?

yeah but you have wiped what there before have a look at :-
```
(3) For security reasons, the MagicMirror (and therefore the Remote Control) is not reachable externally. To change this, configure address, and ipWhitelist in your config.js (see these lines in the sample config). For example change address to 0.0.0.0 and add two allowed devices with IP-Adresses 192.168.0.42 and 192.168.0.50:

address : '0.0.0.0',
port: 8080,
ipWhitelist: ["127.0.0.1", "::ffff:127.0.0.1", "::1", "::ffff:192.168.0.42", "::ffff:192.168.0.50"],"

You can also add multiple devices in an IP range (e.g. all devices with 192.168.0.X):

ipWhitelist: ["127.0.0.1", "::ffff:127.0.0.1", "::1", "::ffff:192.168.0.1/120", "192.168.0.1/24"],

Have a look at config.js.sample to get the originals back.

Then as it is above your router ip address might be 192.168.1.1 so it would be the above but with ::ffff:192.168.1.42, ::ffff:192.168.1.50  you can also put your router address in there but make the last octal 0/24 and you can then access from your desktop.

Then the next big thing you are missing is apiKey: "",         // Optional, See API/README.md for details

you have mm listening on all adapters 0.0.0.0 which correct but the 2[] brackets of your ip whitelist the other side is completely empty.

What is your routers address? Usually its something like 192.168.1.1 if it was that then 192.168.1.0/24 would allow any local ip to access connected internally on your network

@hallonpaj Yeah of course it could you can get a 3.3v relay and its a 2 wire job to GPIO

But what are you going to wire it to?

What you do is put an IR Led on a wire and your Pi is now a universal remote for any device in range via LIRC.
Its a LED + resistor and two wires.

http://www.lirc.org/

Yeah a pi could with the right interface also do powerline comms but your TV can not so that would be a bit pointless
https://www.aliexpress.com/item/3-3V-5V-12V-24V-1-Channel-Relay-Module-Low-Level-Trigger-Optocoupler-Isolation-Relay-Module/32849672414.html?src=google&albslr=221170259&src=google&albch=shopping&acnt=494-037-6276&isdl=y&slnk=&plac=&mtctp=&albbt=Google_7_shopping&aff_platform=google&aff_short_key=UneMJZVf&&albagn=888888&albcp=1706973087&albag=65008162765&trgt=296904914040&crea=en32849672414&netw=u&device=c&gclid=Cj0KCQiAzePjBRCRARIsAGkrSm7WKqheLphSYy6d32kQd-7D9xInwCfxCdYzlxHx6C493on_yqY7e-gaAvVHEALw_wcB&gclsrc=aw.ds

#Bullet proof mirror and how to enable the pi watch dog.

The pi has a watchdog timer circuit built into it that is a prety reasonable means of detecting crashes and forcing an automated reboot.

So first we need to enable it.

First enable watchdog from /boot/config.txt, adding the following line:

dtparam=watchdog=on

# Then install watchdog service:
sudo apt install watchdog

#Uncomment the following line from /etc/watchdog.conf

# Uncomment to enable test. Setting one of these values to '0' disables it.
# These values will hopefully never reboot your machine during normal use
# (if your machine is really hung, the loadavg will go much higher than 25)
max-load-1		= 24
max-load-5		= 18
max-load-15		= 12
#
...
watchdog-device	= /dev/watchdog

So basically constant loads and watchdog will kick in not sure what the time base is think its seconds but the above does the job. Then do a reboot and we can check its running by searching the syslog in /var/log for ‘watchdog’ But how do we know its working? We can test with a fork bomb and overload the Pi. If you have done an OC (Over Clock) on your pi do not run this and for anyone this test is your own decision. I have to say that but yeah you know.

So what we will do is turn off all the swap so the test ends quicker and it doesn’t thrash your flash.

sudo swapoff -a

nano pythonbomb.py
#
import os

while(1):
     os.fork()

So we found that watchdog is running in the syslog and now to test. python3 pythonbomb.py

Doesn’t take long to swamp the system that one The time base has me confused as its very quick to react on a load test but pretty sure the ping test is a minute. Its good how it is and the default values seem to work well as the highest I have ever seen my pi is just above 3 Ping test I tried this by putting in the IP of my desktop 192.168.1.16 which is local but then I just shut down. And right enough after a minute my computer was no longer available the pi restarted.

The only thing I am worried about and I guess this is true that you could enter an IP that may never exist and turn your pi into a rotating boot. Time to put the SD card in a reader and edit your files and remove that watchdog test on another computer I guess. If you don’t have an overzealous internal firewall that putting in your router ip 192.168.1.1 with me would make a good WiFi watchdog Then maybe a internet IP like googles main DNS of 8.8.8.8 might but not sure if you constanty pinging that you may get filtered. 8.8.8.8 is usually what many use just never set up a perm watchdog so honestly can not say bbc.co.uk - 212.58.253.67 did actually take that service down and got bombarded by sysadmins to re-instate and its prob the UK’s unofficial official ping test.

etc/watchdog.conf is a standard linux watchdog file http://www.sat.dundee.ac.uk/psc/watchdog/watchdog-configure.html So you can read up on these. https://manpages.debian.org/stretch/watchdog/watchdog.8.en.html

As per usual you can all my stuff on https://github.com/StuartIanNaylor/MagicMirror-Install-Guide-Raspberry-0-to-3

You sort of need to do this in reverse.

https://hackaday.com/2017/04/23/the-raspberry-pi-as-an-ir-to-wifi-bridge/

But yeah I would do some googling on the pi being a ir reciever / sender

https://www.hackster.io/austin-stanton/creating-a-raspberry-pi-universal-remote-with-lirc-2fd581

http://alexba.in/blog/2013/01/06/setting-up-lirc-on-the-raspberrypi/

Its not your module shaun but bugs elsewhere with freezing modules has some refreshing and then that cascades down to yours.

All I am saying is if you want a fix don’t go the electron way as because its part of the server it gets restarted with the server so you end up due to other modules periodically restarting with the effect that gives of flashing screens and desktop views.
What I am saying is that actually if you use chromium you don’t need to restart the heavy browser as you can keep that in view. You can restart the server and then do a hard refresh and because you start from a restart on the “Ready to go! Please point your browser to:8080” it can have no effect on any module.

That is it Sean and we shall not say argument but its you telling me that isn’t true when it is and I have your module MMM-news on a screen doing the above without restart and no duplication.
Its how I set it up because it has puzzled the hell out of me why with stateless browser / server technology you have lumped them into one?
As a roadmap you prob need to separate client / server or more users like this one will realise it works better when using chromium and not electron even though its only due to the way electron has been implemented.

I think your MMM-News module is the business and a large part of the way I did my setup was to make it work seamlessly with any module without needing browser restarts and it does that perfectly.
PS any chance when you bring the iframe of the full article up in an Iframe that you can enable and activate the DOM distiller so its in ‘Reader mode’?

Sean I have it by the side of me and because I restart the server without need to restart the browser there is no aggregated duplicated articles.
It doesn’t happen and irrespective of who or what you are I have it by the side of me installed it without restart and others after with no duplicates as how could there be when the server has been restarted and the only remnants in cache have been dropped by a hard refresh.

Pfff enough of this as the universe is flat Sean, flat! Do you hear me!
Its a bug for those who have installed electron but if you use Chromium and do it my way its doesn’t matter.

@sean said in MMM-NEWS problem:

Anyway, this module will be newly getting the source to aggregate when it is refreshed (Hard or Normal whatever). And the reason is I’ve made so because I didn’t expect User doing refresh MM by m

I will just quote you once more and say that its not true, but hey.

You can not make a module bridge the stateless gap of browser and server.
The server is incredibly light and its the server that needs to restart the browser can just do a hard refresh and doesn’t need to restart.
It all depends on the way you have installed if your using electron because its in the same process as the server it forces both.
If you install with chromium then you don’t have to restart the browser.

@sean I have MMM-news by the side of me and do not have to restart the browser just the server,

@sean said in MMM-NEWS problem:

REFRESHING MM, not RESTARTING could make problems on many modules(including mines.). Regardless some modules would be not affected, but some would.

It depends on design of module structure. I do some tricks on DOM_OBJECTS_CREATED as a signal for ready of working. When MM is started and be ready for all DOM being prepared, that notification is emitted. Only one time emittance of that notification is expected during execution, not twice or more. But REFRESHING will break that agreement.

When MM Front is refreshed, MM modules would be restarted but some background-procedures (like node_helper.js or related background external scripts) are not killed or restarted properly. Because, many of them are not designed to be REFRESHED.
REFRESHING is some kind of interrupt from User. It couldn’t be predicted or postponed by condition. so, cannot be done killing or restarting process gracefully and safely.

So, It’s better not to REFRESH. RESTART MM instead.

I am replying to that which just isn’t true.
So when refreshing always do a hard refresh which on Chromium is ctrl+F5 pretty sure ctrl+r is the same as F5 and a soft refresh where it keeps the cache.

@sean ctrl+r is a soft refresh not a hard refresh and it retains the cache.

Its only piontless because for some reason you will not simply state the modules you know have problems with hard refreshes.

Needs to be ctrl+F5 with chromium or whatever the shortcut key for hard refresh is.

@sean Just say what it is and which module and I will test it and prove either you or I are right.

Its that simple as every module I install when I click save on config.js I never need to kill my browser and have gone through 5 to 10 modules at least without trouble and without restart.
Just say which modules and lets test to see who is mistaken?

Browsers are stateless and if the server has been reset and the browser drops its cache its the same as running new.