Read the statement by Michael Teeuw here.
CORS, MotionEye & MMM-Remote-Control
-
@sdetweil said in CORS, MotionEye & MMM-Remote-Control:
they check the IP address/name of the client making the request.
localhost is inside the same system
192.168 or 10. or 172. are non routablebip addresses, so sekfvcontainedvsyatens like localhost
0.0.0.0 is undetermined… and is mostly rejected .
as I said, it’s not a valid IP address, so it should never be sent to the other side as part of the requestIts funny though, it is only since MM v.2.17 I have been having issues with MMM_MotionEye and the
address: "0.0.0.0"issue. It was fine before. I don’t know what changed other than CORS. -
@SdeGeata we updated libraries we use, so it could be anywhere.
-
@sdetweil So what would you suggest? Is there another address I can have MotionEye listen on while leaving the Magic Mirror address on 0.0.0.0? I see an option to configure that in MotionEye.conf. I just don’t know what to set it to.
-
-
Its funny though, it is only since MM v.2.17 I have been having issues with MMM_MotionEye
MM is an electron app and electron uses chromium as browser. All browsers are more and more restrictive concerning cors when releasing new versions.
I tested MMM-Motioneye with my setup and was not able to get it running.
Another approach is to use MMM-iFrame instead which worked on my side.
-
@karsten13 Yeah, I was messing with that a little today. I couldn’t find an iframe that was reliable enough.
I ended up installing a Home Assistant add-on called go2rtc to serve the video and on the magic mirror, I installed the MMM-WebView module. It works a lot like an iFrame but more stable.
So far, it seems to be working. I have MotionEye and SecuritySpy sending command line webhooks upon motion triggers to Home Assistant that in turn shows and hides the module on the magic mirror. I would have liked to get MotionEye working, but this actually sems faster and more stable.
Thanks so much for your help though, to both of you.
