ppitkin Posted September 27, 2015 Posted September 27, 2015 I've come accross a strange problem today whilst trying to update my HTLM formatted status email that I have sent to me on a regular basis. The issue (as far as I can tell) appears to be related to the number of characters in the email. My status mail sends me all sorts of information relating to my chalets current status. (see attached image(s) for an example of what it looks like). As it has lots of references to variables and device statuses there are a large number of characters in the file. What I have noticed is that if the file contains 19934 charaters (or less) it is sent out the mail without any problems. If it has ca. 19979 (or more) characters it fails to be sent. There appears to be no error message being placed in the error log. Does anyone else have this problem? Peter.
Scottmichaelj Posted September 27, 2015 Posted September 27, 2015 Sorry cant help but wanted to say what you have done here is very impressive. Are you doing anything else to record these readings in a spreadsheet for charting/graphing? Would be cool for historical purposes.
Michel Kohanim Posted September 27, 2015 Posted September 27, 2015 Hi Peter, Please go to Configuration tab and let me know whether or not Send compact notifications is checked. With kind regards, Michel
ppitkin Posted September 30, 2015 Author Posted September 30, 2015 Michel, so sorry for the delay in replying. I've had a look at the field that you mentioned and it is NOT checked. Peter
Michel Kohanim Posted October 1, 2015 Posted October 1, 2015 Hi Peter, Would you be kind enough to also test with another test email account such as gmail? Also, are you certain you do NOT get any -5000x errors in the error log. With kind regards, Michel
ppitkin Posted October 2, 2015 Author Posted October 2, 2015 Hi Michel, I'm already using a gmail account for SMTP'ing my messages - I experienced a lot of delays in the early days when using the UDI default server so I switched. Below are the entries from the error log for the last few days. Unfortunately you need to understand the codes to make any sense of it so it doesn't help me much. What I have just seen is that my daily updates haven't been sent since Sunday and there are "Sun 2015/09/27 23:59:03 System -50001 -19 " entries at the time that it should be sent. The reason is after testing I forgot to reduce the number of characters back down below the threshold mentioned in my original post (probably forgot to press the SAVE button before exiting ). I have just edited the file and sent a test mail and it worked perfectly. I don't believe it's an HTML error or any sort as I can remove or add charaters anywhere in the file and it will either work or not work depending on the total number of characters. Fri 2015/09/25 03:31:12 System -140007 CLI-HAMW Fri 2015/09/25 03:31:12 System -140007 CLI-HAMW Fri 2015/09/25 03:31:12 System -140007 CLI-HAMW Fri 2015/09/25 03:36:12 System -140007 CLI-HAMW Fri 2015/09/25 03:36:12 System -140007 CLI-HAMW Fri 2015/09/25 03:36:12 System -140007 CLI-HAMW Fri 2015/09/25 08:39:42 System -170001 [uDSockets] HTTP:30 error:6 Fri 2015/09/25 08:39:52 System -170001 [uDSockets] HTTP:32 error:6 Fri 2015/09/25 16:56:19 System -140005 CLI-HAMW Fri 2015/09/25 16:56:24 System -140005 CLI-HAMW Fri 2015/09/25 16:56:29 System -140005 CLI-HAMW Fri 2015/09/25 17:06:19 System -140005 CLI-HAMW Fri 2015/09/25 17:06:24 System -140005 CLI-HAMW Fri 2015/09/25 17:06:29 System -140005 CLI-HAMW Fri 2015/09/25 17:21:20 System -140005 CLI-HAMW Sat 2015/09/26 03:00:37 System -170001 [uDSockets] HTTP:30 error:6 Sat 2015/09/26 03:00:47 System -170001 [uDSockets] HTTP:32 error:6 Sun 2015/09/27 06:41:57 System -50001 -19 Sun 2015/09/27 06:45:19 System -50001 -19 Sun 2015/09/27 06:47:41 System -50001 -19 Sun 2015/09/27 07:10:25 System -50001 -19 Sun 2015/09/27 07:22:15 System -50001 -19 Sun 2015/09/27 07:30:30 System -50001 -19 Sun 2015/09/27 07:41:14 System -5012 32 Sun 2015/09/27 12:39:47 System -170001 [uDSockets] HTTP:31 error:6 Sun 2015/09/27 17:34:14 System -170001 [uDSockets] RSub:31 error:6 Sun 2015/09/27 23:59:03 System -50001 -19 Mon 2015/09/28 03:00:43 System -10 n/a Mon 2015/09/28 03:31:13 System -140007 CLI-HAMW Mon 2015/09/28 03:31:13 System -140007 CLI-HAMW Mon 2015/09/28 03:31:13 System -140007 CLI-HAMW Mon 2015/09/28 03:36:13 System -140007 CLI-HAMW Mon 2015/09/28 03:36:13 System -140007 CLI-HAMW Mon 2015/09/28 03:36:13 System -140007 CLI-HAMW Mon 2015/09/28 04:40:00 System -10 n/a Mon 2015/09/28 19:31:25 System -140005 CLI-HAMW Mon 2015/09/28 20:11:16 System -140008 CLI-HAMW:500 Mon 2015/09/28 23:59:02 System -50001 -19 Tue 2015/09/29 00:19:15 System -5012 35 Tue 2015/09/29 23:59:04 System -50001 -19 Wed 2015/09/30 03:00:59 System -170001 [uDSockets] HTTP:32 error:6 Wed 2015/09/30 03:01:09 System -170001 [uDSockets] HTTP:31 error:6 Wed 2015/09/30 03:01:14 System -170001 [uDSockets] HTTP:31 error:6 Wed 2015/09/30 03:18:24 System -170001 [uDSockets] RSub:29 error:6 Wed 2015/09/30 03:18:29 System -170001 [uDSockets] RSub:29 error:6 Wed 2015/09/30 03:18:34 System -170001 [uDSockets] RSub:29 error:6 Wed 2015/09/30 03:18:39 System -5012 38 Wed 2015/09/30 23:59:02 System -50001 -19 Thu 2015/10/01 14:26:19 System -140000 api.aerisapi.com Thu 2015/10/01 18:09:59 System -5012 39 Thu 2015/10/01 18:10:00 System -5006 uuid:39 Thu 2015/10/01 18:10:00 System -5012 40 Thu 2015/10/01 20:16:21 System -140005 CLI-HAMW Thu 2015/10/01 20:16:27 System -140005 CLI-HAMW Thu 2015/10/01 20:16:32 System -140005 CLI-HAMW Thu 2015/10/01 20:21:21 System -140005 CLI-HAMW Thu 2015/10/01 20:21:26 System -140005 CLI-HAMW Thu 2015/10/01 20:21:32 System -140005 CLI-HAMW Thu 2015/10/01 23:59:02 System -50001 -19 Fri 2015/10/02 03:31:15 System -140007 CLI-HAMW Fri 2015/10/02 03:31:15 System -140007 CLI-HAMW Fri 2015/10/02 03:31:15 System -140007 CLI-HAMW Fri 2015/10/02 03:36:15 System -140007 CLI-HAMW Fri 2015/10/02 03:36:15 System -140007 CLI-HAMW Fri 2015/10/02 03:36:15 System -140007 CLI-HAMW
larryllix Posted October 2, 2015 Posted October 2, 2015 May not be related but... I just discovered with v5.0.2, if I turn off DHCP in ISY, and assign it the same static IP address, none of my notifications get received. And yet, all local and remote access worked just fine. I had to turn DHCP back on to get notifications out.
MWareman Posted October 2, 2015 Posted October 2, 2015 May not be related but... I just discovered with v5.0.2, if I turn off DHCP in ISY, and assign it the same static IP address, none of my notifications get received. And yet, all local and remote access worked just fine. I had to turn DHCP back on to get notifications out. We're the DNS IP addresses the same as assigned by your DHCP server and manually typed when statically setting the IP?
larryllix Posted October 2, 2015 Posted October 2, 2015 We're the DNS IP addresses the same as assigned by your DHCP server and manually typed when statically setting the IP? Yes
jerlands Posted October 2, 2015 Posted October 2, 2015 Tue 2015/09/29 23:59:04 System -50001 -19 Wed 2015/09/30 03:00:59 System -170001 [uDSockets] HTTP:32 error:6 Wed 2015/09/30 03:01:09 System -170001 [uDSockets] HTTP:31 error:6 Thu 2015/10/01 14:26:19 System -140000 api.aerisapi.com This all looks DNS related to me.. You might change to 8.8.4.4 , open Event Viewer "level 3" and run a test message.. Jon...
ppitkin Posted October 2, 2015 Author Posted October 2, 2015 My problem is the sending of emails when the size of the mail reaches a certain limit - I don't see that this would be influenced by the DNS or static IP address. Messages go out fine if they are under ca 19950 characters.
larryllix Posted October 2, 2015 Posted October 2, 2015 ....if the file contains 19934 charaters (or less) it is sent out the mail without any problems. If it has ca. 19979 (or more) characters it fails to be sent. .... Peter. What happens in the quantity gap or are these the only size tests that you have recorded? I was just attempting to nail down the size as a binary number to look for some bit pattern .
jerlands Posted October 2, 2015 Posted October 2, 2015 You might try increasing your timeout but it looks to me by the following errors the problem is either a flaky DNS server or your smtp server is slow. -50001 SMTP SERVER FAILURE -140000 HTTP_CLIENT_DNS_ERROR Jon...
Michel Kohanim Posted October 2, 2015 Posted October 2, 2015 Hi ppitkin, 5000x -19 = WRITE FAILED. This means that the server disconnected the socket. You might want to increase the timeout in SMTP settings though I am not confident this solves the issue. It somehow has to do with the size of the message. With kind regards, Michel
ppitkin Posted October 5, 2015 Author Posted October 5, 2015 Hi Michel, SMTP delay is already set to the mayimum of 10 seconds (10,000 milliseconds) - It doesn't appear possible to set it higher than that in the admin console. I was playing around yesterday trying to find what the character limit was. It seems to change depending on the information in the file. By this I mean if the characters are pure text (and no substitution is performed by the ISY, or if they are a tag (e.g ${sys.node.xx xx xx 1.st} ) where substitution will be performed. Naturally its difficult to determine the exact size of the message that the ISY will be trying to send out after substitution but I have looked at the HTML received in the mail and it appears to be around the 15221 characters where the limit is reached. In addition I have looked to see if this is an issue with the gmail SMTP interface and I am able to send out mails to gmail of a much larger size than this without problems. Not sure is any of that helps in any way. peter.
larryllix Posted October 5, 2015 Posted October 5, 2015 .... Naturally its difficult to determine the exact size of the message that the ISY will be trying to send out after substitution but I have looked at the HTML received in the mail and it appears to be around the 15221 characters where the limit is reached. In addition I have looked to see if this is an issue with the gmail SMTP interface and I am able to send out mails to gmail of a much larger size than this without problems. Not sure is any of that helps in any way. peter. This equates to 0x3B7516 and I can't see any new bits in the quantity. 16,38410 would have been a different story.
ppitkin Posted October 5, 2015 Author Posted October 5, 2015 So I have done some more testing.... I have gone back to basics: Plain text email, no parameters, no html or xml. I have determined the following: 1) a new line eats up 4 characters of space (not 1 or 2 as would have been expected for LF/CR or just LF) 2) The limit appears to be the 32767 integer limit 3) The limit includes the email subject text as well as the body text. 4) I would expect (but didn't test) that the "to" and "From" email adresses are also included in that limit. So my guess would be that the ISY is building a charater string for the email information and the lenght of the character string is limited to 16 bits. Michel, could you check if this is what is happening and look for a possible workaround if ift is. For my HTLM email with paramter substitution I quess there must be some sort of processing on the parameter replacement that causes it to hit the limit even though the number of charaters in the mail is actually much lower - but that is just a guess
Michel Kohanim Posted October 5, 2015 Posted October 5, 2015 Hi ppitkin, Thank you. Did you mention that everything works with gmail? If so, the problem is in SMTP translation from unicode on the server side. Please do let me know if everything works with gmail. With kind regards, Michel
ppitkin Posted October 5, 2015 Author Posted October 5, 2015 ISY is configured to use gmail. I don't think the ISY ever gets to send the mail to gmail as it has a problem with more than 32767 characters. If I use another application I can send mails with more than 32767 characters via gmail smtp
Michel Kohanim Posted October 7, 2015 Posted October 7, 2015 Hi pptkiin, After further review, this seems to be correct: ISY dynamic buffer is 32K so when you use variable substitution, you will reach the limit. I am sorry. With kind regards, Michel
Recommended Posts