[quote=“akbooer, post:40, topic:198812”]My main impediment in testing, ATM, is the lack of hardware which needs this. An alternative is an appropriate website. Any suggestions* for what I could try?[/quote]I can provide access if you would like to try this with a real camera. Or I can be an alpha tester for you…
I am trying to move an amcrest camera from the vera to Openluup and have gotten to make it show livestream on ALTUI. However, I am unable to control it’s PTZ, not even the presets. I have run some test and found that somehow running
luup.inet.wget (“http://camera.ip/cgi-bin/ptz.cgi?action=start&channel=0&code=GotoPreset&arg1=0&arg2=2&arg3=0”,5, username, password) on the vera works while it doesn’t on openluup.
Is there a difference in how the luup.inet.wget function is handled? are the timeout and credentials handled?
Most of the Amcrest cameras require digest authentication. This was just discussed over here: http://forum.micasaverde.com/index.php/topic,63465.msg380840.html#msg380840 Vera seems to know how to try digest authentication if the basic authentication fails.
I’m not 100% sure how you can get the live stream to work, but maybe that uses something else to authorize (or doesn’t need it). Or my theory above is wrong.
I’ve just merged the previous two posts from a separate new thread into this topic.
Yes @rafale77, as @jswim788 has mentioned, this is the discussion to watch.
Yes both, I am being tardy in implementing this, although I see no real technical problem in doing so. I’ve made some steps forward with cameras recently, and it’s important to me to try and get this aspect of openLuup as functional as possible. The SMTP server and email camera triggers were part of that. That then prompted a POP3 server for more general email use, and an implementation of file retention policies to contain the burgeoning image files. There are going to be some limits as to what is possible, in particular video streams, for which I mostly rely on AltUI.
There are reasons for my slowness here, not least the other demands you have placed on me recently (but other more significant ones too!) I just need a bit of time to sort myself out.
Thanks.
[quote=“jswim788, post:44, topic:198812”]Most of the Amcrest cameras require digest authentication. This was just discussed over here: http://forum.micasaverde.com/index.php/topic,63465.msg380840.html#msg380840 Vera seems to know how to try digest authentication if the basic authentication fails.
I’m not 100% sure how you can get the live stream to work, but maybe that uses something else to authorize (or doesn’t need it). Or my theory above is wrong.[/quote]
Well I am sure now. I brute force it by using a Oscommand and curl from ALTUI and it works.
curl --digest -u "username:password" "http://ipaddress/cgi-bin/ptz.cgi?action=start&channel=0&code=GotoPreset&arg1=0&arg2=1&arg3=0"We could use an os.execute line in my xml instead of luup.inet.wget…
I really, really, really, don’t recommend this.
Just give me time to fix it.
PM me if you want a sob story about why I’m not as fast as fixing things as @amg0 at the moment (maybe I never was!)
ok I won’t do it and wait. But at least we know for sure that jswim788 is correct in his assumption.
Ok found another way to do this:
I went here:
took the http-digest.lua file and dropped it in
/usr/share/lua/5.1 amongst a few other lua modules. (Pretty sure I could have dropped it in the openLuup folder too)
Then used then tested my camera with
local http_digest = require "http-digest"
local url = "the camera API URL I needed"
local b, c, h = http_digest.request(url)
I could use this in my Amcrest Plugin. @akbooer, thoughts?
I attached the lua file.
Amcrest Dahua Camera Plugin available. Don’t want to publish as of yet as it uses a work around which should really be integrated into openLuup. I will revise it as openLuup evolves.
[url=https://github.com/rafale77/Amcrest-Dahua-Openluup]https://github.com/rafale77/Amcrest-Dahua-Openluup[/url]
I have a stable openluup-ALTUI system (Z-Way, Netatmo, Reactor, MySensors (two gateways), Virtual Sensor, DarkSky weather) bridged to a Vera Light and running on a Rpi3B+. I tried to configure two cameras, a Foscam Camera FI8919w and a D-Link DCS-932L in openLuup in order to, after I getting them working in openLuup, delete them from the Vera Light. I did as follows:
I created a device with I_openLuupCamera1.xml (impl_file) and D_DigitalSecurityCamera1.xml (device_file). Two devices are created, the Camera device and the Motion Sensor device of the camera. To test the Foscam camera, I filled in the ip-address of the Camera, as mentioned earlier in the tread: “The camera’s device implementation file may be set on the openLuup device’s Attributes page, followed by a Luup reload. The only other significant parameters are the usual: ip attribute, and the URL and DirectStreamingURL device variables”. However, these last two variables are not formed and thus not present on the Attribute page and also not on the Variable page.
I tested the smtp-mail server with the camera in debug mode by putting this in Lua Startup:
– debug smtp
do – SMTP debug
local smtp = require “openLuup.smtp”
smtp.ABOUT.DEBUG = true
end
I see than, that the mail connection of Motion Sensor of the camera is working, but it is clear that without url and streaming url no image is transported.
Can a direction being given for a possible solution? I have a gut feeling, that it is something simple, but such a feeling does not help much. Or maybe the camera is not compatible.
Thanks in advance for any help.
Attributes are not the same as variables and appear on different device tabs. The IP attribute should be an empty box in the Attributes tab and may be filled in with the appropriate IP:PORT, e.g. 123.45.67.89:88. If it’s not there, then create it in Lua Test with
luup.attr_set ("ip", "123.45.67.89:88", 42)By default, a new device is given variables which are defined with defaults in the service file(s). Alas, there is no default for DirectStreamingURL, but you can create it manually with this one-liner in the Lua Test window:
luup.variable_set ("urn:micasaverde-com:serviceId:Camera1", "DirectStreamingURL", "/cgi-bin/CGIStream.cgi?cmd=GetMJStream&usr=ramwal&pwd=xxxx", 42)…replacing the string value and device number with the required ones.
I see than, that the mail connection of Motion Sensor of the camera is working, but it is clear that without url and streaming url no image is transported.
No, that’s not quite true. In order to make the email trigger efficient, it does not do anything with the image attachment, even though it will (should) be there in the received message. If you want to save the image, you simply need to use the email address images@openLuup.local. A trigger will still be generated. Here’s the Console > SMTP page from one of my systems:
SMTP eMail Server, Sun Aug 26 15:14:53 2018
Received connections:
IP address #connects date time
172.16.42.170 15 2018-08-25 23:56:24
Registered email sender IPs:
Address #messages for device
172.16.42.170 15 [346] Foscam
Registered destination mailboxes:
Address #messages for device
events@openLuup.local 15 [2] openLuup
images@openLuup.local 15 [2] openLuup
mail@openLuup.local 0 [2] openLuup
openLuup@openLuup.local 0 [2] openLuup
postmaster@openLuup.local 0 [0] system
test@openLuup.local 0 [0] system
Blocked senders:
eMail address
spam@not.wanted.com This is for a camera at 172.16.42.170, which has clearly sent 15 triggers since the last reload. Those messages have been received both by the events and images mailboxes, even though they were only sent to images. This is a special feature of the openLuup camera code implementation and not generally the case - if you send an image from elsewhere it will not trigger anything. The message, although it appears in two mailboxes is only sent once (again, for efficiency.)
Can a direction being given for a possible solution? I have a gut feeling, that it is something simple, but such a feeling does not help much. Or maybe the camera is not compatible.
I hope this helps, but ask again if not clear. Obviously the documentation is not up to par on this issue.
@akbooer, Thank you for explaining. Toke your advise, I created two devices for two cameras. A D-Link DCS-932L and a Foscam FI8919w, both older cameras with the settings below and they are both giving an image on the camera device. So far so good.
[code]-- Foscam FI8919w
luup.attr_set (“ip”, “192.168.0.120”, 93)
luup.attr_set (“ip”, “192.168.0.120”, 94)
luup.variable_set (“urn:micasaverde-com:serviceId:Camera1”, “DirectStreamingURL”, “/videostream.cgi?user=ramwal&pwd=xxx”, 93)
– D-Link DCS-932L
luup.attr_set (“ip”, “192.168.0.15”, 95)
luup.attr_set (“ip”, “192.168.0.15”, 96)
luup.variable_set (“urn:micasaverde-com:serviceId:Camera1”, “DirectStreamingURL”, “/mjpeg.cgi?usr=admin&pwd=xxx”, 95)[/code]
A motion trigger for the DCS-932l camera generated the following debug output:
2018-08-30 16:19:46.018 openLuup.smtp:: (openLuup.smtp v18.4.12) [192.168.0.71]
2018-08-30 16:19:46.018 openLuup.smtp:: SEND: 220 (openLuup.smtp v18.4.12) [192.168.0.71] Service ready
2018-08-30 16:19:46.023 openLuup.smtp:: EHLO WebCAM
2018-08-30 16:19:46.023 openLuup.smtp:: SEND: 250 AUTH LOGIN
2018-08-30 16:19:46.027 openLuup.smtp:: AUTH LOGIN
2018-08-30 16:19:46.027 openLuup.smtp:: SEND: 334 VXNlciBOYW1lAA==
2018-08-30 16:19:46.032 openLuup.smtp:: b3BlbmhhYmlhbg==
2018-08-30 16:19:46.032 openLuup.smtp:: SEND: 334 UGFzc3dvcmQA
2018-08-30 16:19:46.066 openLuup.smtp:: cm9zYWNhbmluYQ==
2018-08-30 16:19:46.066 openLuup.smtp:: SEND: 235 Authentication successful
2018-08-30 16:19:46.079 openLuup.smtp:: MAIL FROM:<D-Link@study.local>
2018-08-30 16:19:46.079 openLuup.smtp:: SEND: 250 OK
2018-08-30 16:19:46.082 openLuup.smtp:: RCPT TO:<images@openLuup.local>
2018-08-30 16:19:46.082 openLuup.smtp:: SEND: 250 OK
2018-08-30 16:19:46.097 openLuup.smtp:: DATA
2018-08-30 16:19:46.098 openLuup.smtp:: SEND: 354 Start mail input; end with <CRLF>.<CRLF>
2018-08-30 16:19:47.761 openLuup.smtp:: #data lines=2779
2018-08-30 16:19:47.761 openLuup.smtp:: Deliver Mail:
2018-08-30 16:19:47.761 openLuup.smtp:: Data lines: 2779
2018-08-30 16:19:47.761 openLuup.smtp:: Sender: D-Link@study.local
2018-08-30 16:19:47.761 openLuup.smtp:: SEND: 250 OK
2018-08-30 16:19:47.761 openLuup.smtp:: Mail Delivery job
2018-08-30 16:19:47.762 openLuup.smtp:: IP listener 192.168.0.15
2018-08-30 16:19:47.762 openLuup.smtp:: EMAIL delivery to handler for: 192.168.0.15
2018-08-30 16:19:47.763 openLuup.smtp:: Recipient #1 images@openLuup.local
2018-08-30 16:19:47.763 openLuup.smtp:: EMAIL delivery to handler for: images@openLuup.local
2018-08-30 16:19:47.763 openLuup.smtp:: Content-Type: multipart/mixed; boundary="===Message_0123456789"
2018-08-30 16:19:47.763 openLuup.smtp:: Boundary: ===Message_0123456789
2018-08-30 16:19:47.772 openLuup.smtp:: #parts: 8
2018-08-30 16:19:47.773 openLuup.smtp:: Content-Type: text/plain; charset=us-ascii
2018-08-30 16:19:47.773 openLuup.smtp:: Boundary: --none--
2018-08-30 16:19:47.773 openLuup.smtp:: content-transfer-encoding --none--
2018-08-30 16:19:47.774 openLuup.smtp:: Content-Type: image/jpeg; name="20180830_161942_01.jpg"
2018-08-30 16:19:47.774 openLuup.smtp:: Boundary: --none--
2018-08-30 16:19:47.775 openLuup.smtp:: content-transfer-encoding base64
2018-08-30 16:19:47.778 openLuup.smtp:: Content-Type: image/jpeg; name="20180830_161942_02.jpg"
2018-08-30 16:19:47.779 openLuup.smtp:: Boundary: --none--
2018-08-30 16:19:47.780 openLuup.smtp:: content-transfer-encoding base64
2018-08-30 16:19:47.783 openLuup.smtp:: Content-Type: image/jpeg; name="20180830_161942_03.jpg"
2018-08-30 16:19:47.783 openLuup.smtp:: Boundary: --none--
2018-08-30 16:19:47.784 openLuup.smtp:: content-transfer-encoding base64
2018-08-30 16:19:47.787 openLuup.smtp:: Content-Type: image/jpeg; name="20180830_161942_04.jpg"
2018-08-30 16:19:47.787 openLuup.smtp:: Boundary: --none--
2018-08-30 16:19:47.789 openLuup.smtp:: content-transfer-encoding base64
2018-08-30 16:19:47.791 openLuup.smtp:: Content-Type: image/jpeg; name="20180830_161942_05.jpg"
2018-08-30 16:19:47.792 openLuup.smtp:: Boundary: --none--
2018-08-30 16:19:47.793 openLuup.smtp:: content-transfer-encoding base64
2018-08-30 16:19:47.796 openLuup.smtp:: Content-Type: image/jpeg; name="20180830_161942_06.jpg"
2018-08-30 16:19:47.796 openLuup.smtp:: Boundary: --none--
2018-08-30 16:19:47.797 openLuup.smtp:: content-transfer-encoding base64
2018-08-30 16:19:47.879 openLuup.smtp:: QUIT
2018-08-30 16:19:47.879 openLuup.smtp:: SEND: 221 (openLuup.smtp v18.4.12) [192.168.0.71] Service closing transmission channel
2018
6 image files were saved in the /etc/cmh-ludl/images directory and everything looks OK.
Now the debug output for the Foscam FI8919w camera:
2018-08-30 15:52:34.961 openLuup.smtp:: (openLuup.smtp v18.4.12) [192.168.0.71]
2018-08-30 15:52:34.962 openLuup.smtp:: SEND: 220 (openLuup.smtp v18.4.12) [192.168.0.71] Service ready
2018-08-30 15:52:34.970 openLuup.smtp:: EHLO ipcamera
2018-08-30 15:52:34.970 openLuup.smtp:: SEND: 250 AUTH LOGIN
2018-08-30 15:52:35.003 openLuup.smtp:: AUTH LOGIN
2018-08-30 15:52:35.003 openLuup.smtp:: SEND: 334 VXNlciBOYW1lAA==
2018-08-30 15:52:35.009 openLuup.smtp:: b3BlbmhhYmlhbg==
2018-08-30 15:52:35.010 openLuup.smtp:: SEND: 334 UGFzc3dvcmQA
2018-08-30 15:52:35.014 openLuup.smtp:: cm9zYWNhbmluYQ==
2018-08-30 15:52:35.015 openLuup.smtp:: SEND: 235 Authentication successful
2018-08-30 15:52:35.020 openLuup.smtp:: MAIL FROM:<Foscam@study.local>
2018-08-30 15:52:35.021 openLuup.smtp:: SEND: 250 OK
2018-08-30 15:52:35.025 openLuup.smtp:: RCPT TO:<images@openLuup.local>
2018-08-30 15:52:35.025 openLuup.smtp:: SEND: 250 OK
2018-08-30 15:52:35.029 openLuup.smtp:: DATA
2018-08-30 15:52:35.029 openLuup.smtp:: SEND: 354 Start mail input; end with <CRLF>.<CRLF>
2018-08-30 15:52:44.113 openLuup.smtp:: #data lines=8020
2018-08-30 15:52:44.114 openLuup.smtp:: Deliver Mail:
2018-08-30 15:52:44.114 openLuup.smtp:: Data lines: 8020
2018-08-30 15:52:44.114 openLuup.smtp:: Sender: Foscam@study.local
2018-08-30 15:52:44.114 openLuup.smtp:: SEND: 250 OK
2018-08-30 15:52:44.115 openLuup.smtp:: Mail Delivery job
2018-08-30 15:52:44.115 openLuup.smtp:: IP listener 192.168.0.120
2018-08-30 15:52:44.115 openLuup.smtp:: EMAIL delivery to handler for: 192.168.0.120
2018-08-30 15:52:44.116 openLuup.smtp:: Recipient #1 images@openLuup.local
2018-08-30 15:52:44.116 openLuup.smtp:: EMAIL delivery to handler for: images@openLuup.local
2018-08-30 15:52:44.117 openLuup.smtp:: Content-Type: multipart/mixed; boundary="smtp_msg_boundary"
2018-08-30 15:52:44.117 openLuup.smtp:: Boundary: smtp_msg_boundary
2018-08-30 15:52:44.143 openLuup.smtp:: #parts: 7
2018-08-30 15:52:44.143 openLuup.smtp:: Content-Type: 00626E4E1116(FI8919w)_m20180830155414.jpg
2018-08-30 15:52:44.143 openLuup.smtp:: Boundary: --none--
2018-08-30 15:52:44.146 openLuup.smtp:: content-transfer-encoding base64
2018-08-30 15:52:44.151 openLuup.smtp:: Content-Type: 00626E4E1116(FI8919w)_m20180830155415.jpg
2018-08-30 15:52:44.151 openLuup.smtp:: Boundary: --none--
2018-08-30 15:52:44.154 openLuup.smtp:: content-transfer-encoding base64
2018-08-30 15:52:44.159 openLuup.smtp:: Content-Type: 00626E4E1116(FI8919w)_m20180830155417.jpg
2018-08-30 15:52:44.159 openLuup.smtp:: Boundary: --none--
2018-08-30 15:52:44.162 openLuup.smtp:: content-transfer-encoding base64
2018-08-30 15:52:44.168 openLuup.smtp:: Content-Type: 00626E4E1116(FI8919w)_m20180830155419.jpg
2018-08-30 15:52:44.169 openLuup.smtp:: Boundary: --none--
2018-08-30 15:52:44.174 openLuup.smtp:: content-transfer-encoding base64
2018-08-30 15:52:44.180 openLuup.smtp:: Content-Type: 00626E4E1116(FI8919w)_m20180830155420.jpg
2018-08-30 15:52:44.181 openLuup.smtp:: Boundary: --none--
2018-08-30 15:52:44.186 openLuup.smtp:: content-transfer-encoding base64
2018-08-30 15:52:44.193 openLuup.smtp:: Content-Type: 00626E4E1116(FI8919w)_m20180830155422.jpg
2018-08-30 15:52:44.193 openLuup.smtp:: Boundary: --none--
2018-08-30 15:52:44.199 openLuup.smtp:: content-transfer-encoding base64
2018-08-30 15:52:44.205 openLuup.smtp:: ERROR delivering email to handler for: images@openLuup.local : [string "openLuup/L_openLuup.lua"]:581: attempt to index local 'ctype' (a nil value)
2018-08-30 15:52:44.277 openLuup.smtp:: QUIT
2018-08-30 15:52:44.277 openLuup.smtp:: SEND: 221 (openLuup.smtp v18.4.12) [192.168.0.71] Service closing transmission channel
An error is generated and no files are stored in de images directory. There must be something wrong and I do not know how to fix this. I did look into L_openLuup.lua file, but have no idea what to do and i don’t want damage things.
Further comments:
I don’t see messages generated for events@openLuup.local as is the case with your example above.
[code]SMTP eMail Server, Thu Aug 30 16:45:09 2018
Received connections:
IP address #connects date time
192.168.0.15 2 2018-08-30 16:19:46
192.168.0.120 5 2018-08-30 15:52:34
Registered email sender IPs:
Address #messages for device
192.168.0.120 5 [93] Foscam FI8919w
192.168.0.15 2 [95] D-Link DCS-932L
Registered destination mailboxes:
Address #messages for device
events@openLuup.local 0 [2] openLuup
images@openLuup.local 7 [2] openLuup
mail@openLuup.local 0 [2] openLuup
openLuup@openLuup.local 0 [2] openLuup
postmaster@openLuup.local 0 [0] system
test@openLuup.local 0 [0] system
Blocked senders:
eMail address
spam@not.wanted.com
[/code]
A last point, I noticed on Console - Files - Images, that only a small strip is visible and not the whole image.
I would very much appreciate, if you can comment on this all.
Thanks in advance.
Indeed. That’s not a bad start.
[code] 2018-08-30 15:52:44.205 openLuup.smtp:: ERROR delivering email to handler for: images@openLuup.local : [string "openLuup/L_openLuup.lua"]:581: attempt to index local 'ctype' (a nil value) [/code] An error is generated and no files are stored in de images directory.
Less good, but one out of two isn’t bad!
I can fix the error message, which arises from the fact that there are so many options which cameras use to send images. The DCS camera produces an expected message content type:
2018-08-30 16:19:47.774 openLuup.smtp:: Content-Type: image/jpeg; name="20180830_161942_01.jpg"However, the Foscam one does not:
2018-08-30 15:52:44.143 openLuup.smtp:: Content-Type: 00626E4E1116(FI8919w)_m20180830155414.jpgTo actually work out how to save the image I’ll need a snapshot of the entire received message. If you know how to do that, then fine, if not, I’ll need to issue further instructions.
Further comments: I don't see messages generated for events@openLuup.local as is the case with your example above.
Interesting. I’ll have to check on that, I may have issued you with incorrect instructions.
A last point, I noticed on Console - Files - Images, that only a small strip is visible and not the whole image.
Yes, the images page in the console is a work in progress. Simply right-click on the image link and open it in a new browser tab or page and it should appear full size.
Hi, @akbooer
Thank you for responding.
To actually work out how to save the image I'll need a snapshot of the entire received message. If you know how to do that, then fine, if not, I'll need to issue further instructions.Could you show me a short instruction how to get the message, you've asked for, if you don't mind? I am still learning.
If you set the camera to send the email to mail@openLuup.local, then the message will be saved in a file in cmh-ludl/mail/.
Or, if you prefer, you can send it to test@openLuup.local and the entire text of the message will appear in the log file.
[quote=“akbooer, post:54, topic:198812”]
Further comments:
I don’t see messages generated for events@openLuup.local as is the case with your example above.
Interesting. I’ll have to check on that, I may have issued you with incorrect instructions.[/quote]
That was, in fact, the case. Checking my camera setup, I see that it sends to both images@… and events@…
The message is still sent from the camera only once to the SMTP server, but then distributed internally to those on the To: list. The events mailbox just saves the subject line, so it’s very compact, whereas images does,indeed, save all the images. Sending to either/both will still cause the associated motion sensor to trigger.
Sorry about that.
No big deal. There is nothing to be sorry about. It is good to know how it works.
By the way, in the mail configuration of the DCS-932L camera there is only one receiver email to define, while the Foscam FI8919w camera contains even 4 of them.
If you set the camera to send the email to mail@openLuup.local, then the message will be saved in a file in cmh-ludl/mail/.
Or, if you prefer, you can send it to test@openLuup.local and the entire text of the message will appear in the log file.
Herewith I send you the whole mail message (see attachment), that is generated bij Foscam FI8919w camera upon triggering. I think, that the content is raw image file.
See the first part and the end part and the end part of the message.
[code]Received: from (ipcamera) [192.168.0.120]
by (openLuup.smtp v18.4.12) [192.168.0.71];
Fri, 31 Aug 2018 13:44:10 +0100
From: Foscam@study.local
To: images@openLuup.local
To: mail@openLuup.local
To: test@openLuup.local
Subject: =?utf-8?B?MDA2MjZFNEUxMTE2KEZJODkxOXcpIG1vdGlvbiBhbGFybSBhdCAyMDE4MDgzMTEzNDQ0MA==?=
Date: Fri, 31 Aug 2018 13:44:49 +0200
MIME-Version: 1.0
X-Mailer: sSMTP
Content-Type: multipart/mixed;
boundary=“smtp_msg_boundary”
–smtp_msg_boundary
Content-Type: image/jpeg;
name=“=?utf-8?B?MDA2MjZFNEUxMTE2KEZJODkxOXcpX20yMDE4MDgzMTEzNDQ0MC5qcGc=?=”
Content-Transfer-Encoding: base64
/9j/2wBDABcQERQRDhcUEhQaGBcbIjklIh8fIkYyNSk5UkhXVVFIUE5bZoNvW2F8Yk5QcptzfIeLkpSS
WG2grJ+OqoOPko3/2wBDAQEYGhoiHiJDJSVDjV5QXo2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2N
jY2NjY2NjY2NjY2NjY2NjY2NjY3/wAARCAHgAoADASEAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAA
AAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0Kx
wRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4
[/code]
[code]XHUMK9As0vEbB5lI5AP9Kp2d0ip5Vw2RnjPoaDzyUGXTbgXFqSyH7wzwR6Gtn9zq9ulzav5dwnQ91Pof
amzuASxX6m0vF8u4H4ZPqKI53tP9F1AbozwspHBHvXIcobJtNO6EedaHnbnlPp7U4xbj9t01x83307N+
HrXQMVr5biHy1DJKThlx0q3bQiGMDv1r41qx6AXbbbZ/cYqtpx/esAeNtfMHtF+iuI5CtLbxB9/lruPf
FOjbHGBiv0Rao8FkucDNM80d814qVyLjHWGTqcGmmBlGY3yK+qTa3EOjEu09Qc96XM6npuFT7p4eoecw
OCmKfjeMkV5jVjrvcPLUHqaXYtcXMx6CMvoajKGvpUz5tjSp9Kei7ecc17jZxjgKJWIXivhuoxsUhIbO
OKYxy2TXv21Oy5z2pyl5yO2apZr9NPnz/9k=
–smtp_msg_boundary–
[/code]
I hope this helps to elucidate the problem. Thanks
Hi @akbooer,
If you don’t mind, i want to bring another issue under your attention concerning my cameras. I think it is an issue, but I am not sure.
It does not make a difference, when I ARM or BYPASS the Motion Sensor device in openLuup. The trigger generates a message in both settings. Only if I disable motion detection on the camera, there are not coming messages in the mail. I don’t know if this is desired behaviour or it is designed this way.
Not sure what you mean by this. Certainly, if the camera sends a message to events@… or images@… then those messages will appear in the respective mailboxes, AND the motion sensor device will trigger. This will happen regardless of the ARM/BYPASS state of the motion sensor.
Only if I disable motion detection on the camera, there are not coming messages in the mail. I don't know if this is desired behaviour or it is designed this way.
So I guess the answer is, yes, that’s the way it’s currently implemented. A trigger event will save event and images emails whether or not the sensor is armed. You raise a good point as to whether it would be more useful to do so for just the armed case. I’m certainly open to discussion on this… anyone have suggestions for use cases?
PS: Thanks for the data on the image error problem. I am totally confused as to why the log you showed earlier displays a different content-type string from the actual message file attached. This may have to wait at least a couple of weeks to resolve as I am currently away from my development system.