MQTT Unexpected Disconnects


#1

We are currently testing using MQTT and Flexy units through Basic Script.

The script I am testing with is from some examples from the HMS site and the eWon site. Please review the attached backup to see if there are any tips that can be provided to explain the unexpected disconnects that show in the log file.

Also please note that the logging for MQTT is posted with a time stamp that is in a different time zone than what is set on the Flexy unit. This unit has the timezone set to UTC time and all the other log messages are timestamped with the UTC timezone. MQTT logging is not displayed in the timezone that is set on the unit. It is logged in the timezone the unit is located in.MOVED TO STAFF NOTE (259.5 KB)


#3

Ted,

Can you check:

  1. if another client is started and connects with the same client ID?

  2. if the MQTT client accesses a topic that it is not authorized to, either for publishing or subscribing.

Also, please try changing from UDP (port 1194) to TCP (port 443) to see if it makes a difference.

In regards to the time zone. In the config.txt I found these settings:

Timezone:Etc/GMT
TimeZoneOffset:0

You will want to update one of these, for example:

Timezone:America/New_York

or

TimeZoneOffset:300

Thanks,

Kyle


#5

Currently there is only one device setup on the IOTHUB

Just connecting to the same topic every time.

UDP and TCP ports are only for connecting with VPN connection correct? I am not using the VPN connection at this time. Just using Internet connection.

I want everything to log in UTC time. Currently the Flexy logs everything but MQTT in UTC. Anything to do with MQTT logging logs in a different time zone.


#6

#7

Ted,

What is happening is, pings are being sent out (PINGREQ) and sometimes they are getting a response (PINGRESP) immediately, and other times there is no response within 30 seconds, which causes the system to think it’s disconnected and has to reconnect.

Some of these parameter can be changed in the Flexy, like “keepalive”, but others would have to be adjusted in Azure.

Can you try switching to an ethernet connection to see if the issue goes away or stays the same? That way we can possibly rule out any connection issue.

Also, can you clarify which MQTT logs you are looking at? Is it the real-time logs (rtevents.txt)? Those look like they’re in sync with the BASIC logs and Event logs (events.txt). Can you provide a screenshot of what you are looking at?

Thanks,

Kyle


#8

This is the real time logs. Notice the date/time of the log versus the date/time on the unit in the lower right


#9

Can we get access to Flexy, either by Teamviewer or with a temporary eCatcher account?


#11

You can through TeamViewer. Give me a call and we can get logged on.


#12

What is the phone number?


#13

xxxxxxxxxx


#15

Can I give you a call in the morning? (We are on Eastern time.) That way I can also have Simon from Ewon in Belgium also take a look.


#16

Sure can I am central time.


#17

Hi Ted, just tried calling to get the Teamviewer info, but didn’t get through…


#18

I am available now


#19

I am available now


#20

We were able to get the MQTT logs to use UTC, by unchecking the “Log in UTC” box. Because the Flexy was already using UTC, this was not necessary.

According to Simon: “Because the RT (real-time) logs EBD (export block descriptor) that the UI uses as well it does not contain the time as a date but as an epoch time (UNIX time - seconds from epoc) we have to convert it. In the eWON you get the date and the epoch time directly from the eWON.”