@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.