Mobilinc Pro Connection Issues since iOS 14.3 Update

[InsteonNut]

@vspeteI'm just now getting caught up on this thread after the holidays. How are you connecting to the ISY in MobiLinc? Are you using a direct IP connection or our MobiLinc Connect service? Have you tried both? Are there different behaviors?

Wes

[vspete]

@InsteonNut I am connecting direct to my ISY on both the local network (HTTP) and remotely (HTTPS).  Both are working fine from Mobilinc Pro on iOS 14.3.  Since the iOS 14.3 upgrade, any attempt to use the iWatch extension causes connection problems. After removing (not using) the iWatch extension, these issues no longer cause the app to have connection issues. I have not tried Mobilinc Connect as I have a ISY portal account and understand I can use only one or the other. My network services license I believe is bundled with my ISY Portal account. 

I prefer direct connection to ISY (local or port forwarded through my router).  I have only seen the "subscription" issue once. One reboot of the ISY eliminated this issue. 

In terms of behaviors, when I connect via HTTPS from Mobilinc it takes more time to establish a connection and refresh the dashboard. I expect this is due to my use of a 2048 bit encryption key in my certificate (it seemed to go faster when the key was only 512).

I do believe the connectivity issue I have been experiencing is related to using the Mobilinc Pro iWatch extension. 

[asbril]

5 hours ago, vspete said:

@asbril, I have determined that the issues that prompted this topic are associated with using the Mobilinc iWatch extension after the 14.3 iOS update.  Just to confirm, did you test Mobilinc Pro on your iWatch?

I will review Home Assistant as a possible Mobilinc alternative.  Thanks...

I usually never use Mobilinc on my Apple Watch but I just checked and it seems to work fine.

[InsteonNut]

@vspete

A 2048-bit cert will take the ISY sometime to setup that SSL handshake. It's not obvious to me if that's the issue at play here or not, but three things I would recommend:

1. For performance, our MobiLinc Connect portal will give you the best connection performance with current best-practice security. Understood that you have ISY Portal. In that case, I would back off the cert back down to 512 for the best connection performance. 

2. As a test, configure MobiLinc (and by extension, the Apple Watch app) to only use HTTP to eliminate HTTPS as a possible vector and test.

3. Update the watch to the latest OS (If not already).

I'm not aware of anything that changed in iOS 14.3. What I do know is that if the subscription channel is abruptly cut off from the ISY, the ISY (the last time I checked and recall) will keep that "slot" around for 10 minutes before timing out and clearing the slot for another connection. The ISY has 10 slots. Between Admin Console, MobiLinc, Watch, and Node servers, this may fill up quickly especially if the Watch isn't network disconnecting properly. 

Wes

[vspete]

@asbril, thanks for trying.  When I first try an action on the iWatch, it works.  It is when I try multiple actions over a relatively short period of time that causes issues.  Also I have notice that sometimes when I would select the app in the watch dock it would already be displaying a connection issue that must have occured in the past.  I think Wes may by on the right track in my case so I will address his comments.

@InsteonNut , thanks for the recommendations. I think we may be closing in on the issue.

1. I appreciate the additional time associated with the 2048 bit handshake.  I accept that when using https.  It is either that or establishing a VPN connection to my Fortigate and then going http.

2. I have set mobilinc to http (only). For the testing and reporting these connection issues.

3. My watch has been running v7.2 (the latest), since it was released. 

I think your discussion regarding subscription channel slots and their "release" may be where the issue is.  My ISY is running firmware 5.2.0. It was my understanding that the number of "slots" available (at least for Nodeservers), has been greatly increased sometime in the recent past.  I currently connect to 5 nodeservers, mobilinc, watch, admin console.  My nodeservers are hosted locally and I receive a text message if any of their connections go offline (this does not happen unless I do it deliberately).

However, I am not particularly careful in fully terminating the Mobilinc App and it sometime is left running on my iPhone.

The iWatch connection appears to not terminate fairly frequently (until it times out - 10 minutes as you suggest??). I say this, because I can fire up the watch, successfully turn on a scene and go back to watch face.  A minute or so later if I go to the watch app and attempt to turnoff the scene, there is no response for 10s of seconds. If I attempt to connect to the ISY via the phone app, It hangs and doesn't display the dashboard until the scene eventually responds to the watch command. 

The lack of reasonable responsiveness causes me to repeat commands to the watch which probably overflows queues and/or cause other issues.

Addendum:  I just entered a room that had an insteon device that was on. I opened the iwatch app and it showed the scene as off.  After about 10 seconds the iwatch app crashed (closed itself), I didn't touch the watch screen. I reopened the iwatch app and it correctly displayed the device status and didn't crash.

Edited January 5, 2021 by vspete

[InsteonNut]

Thanks @vspete

I checked 4.8.0 and 5.3.0 FW for the ISY and both still report a total of 10 sockets for subscriptions. Note that this is different than issuing requests to the ISY. You can see what's in-use by going to: http://ISY-IP-ADDRESS/rest/subscriptions from a web browser and logging in with your Admin Console username/password. 

What I don't know is if Node Servers also use this pool or not.

My guess is that between iOS/WatchOS and the ISY the network connection isn't getting closed out in a way where everyone is happy resulting in the ISY holding onto old (dead) subscriptions and locking out new connections until either:

1. Old subscriptions expire and are cleared.

2. The ISY is rebooted to force all to clear.

If this started with the latest iOS 14.3, then it seems likely that Apple has changed a behavior somewhere.

Wes

[vspete]

Thanks @InsteonNut

I can confirm that NodeServers DO NOT use this pool. When I logged into this pool, no subscriptions were in use. When I opened Mobilinc on the iphone, it immediately took a slot. The slot was released when the app was closed.  If the app was just placed into background, it held the slot until something timed out.  Tried this numerous times always behaved the same way.

When opening the iwatch app, things are less predictable.  Sometimes it gets one slot and later gets a second slot.  Sometimes when I open iwatch app, I am able to control a device with the watch (the watch display sometimes accurately displays status and sometimes it doesn't.) I have also been able to open the iWatch App and use it successfully with no subscription slots shown to be in use (yes, I refreshed the browser many times - no change - no subscriptions in use). 

I have seen one one subscription when the iphone app and iwatch apps are both open and sometimes I have seen two subscriptions.  I have never seen more that 2 of the 10 subscriptions used at the same time. I do not have the console open.

I do believe that something in the Apple world has changed. It may be iOS 14.3 or possibly iWatch 7.2. These updates were released at about the same time. 

Apple has been making changes to improve security which may be an issue.  A number of my iWatch apps (MyQ, TC2.0) for example, now frequently require me to open and authenticate the iphone app prior to allowing the iwatch app to connect to the service. I believe this requirement is relatively new and clearly detracts from the convenience of the iWatch app due to both the frequency and unpredictability of needing to open the phone app.   Coupled with having to remove the phone from one's pocket and either removing a mask for facial recognition and/or typing a long password into the iphone in order to launch the iphone app as a prerequisite to allowing the iwatch app to operate is quite annoying.  Don't know if this has any relation to the behavior issues we are experiencing with Mobilinc, but things are different.

Thanks again for helping me understand better what is going on.

[InsteonNut]

Hi @vspete

Quote

 If the app was just placed into background, it held the slot until something timed out. 

Yes, this is by design. If you background MobiLinc, it will hold the subscription for up to 2 minutes. We found that users would frequently go in and out of MobiLinc in bursts and going through the reconnection logic and syncing with the ISY was added overhead and a slower user experience. Instead, by keeping the connection alive for for a few minutes when backgrounded, this gives a better user experience during these burst activities.

Quote

I have never seen more that 2 of the 10 subscriptions used at the same time.

Ok, this is good and what I would generally expect. It is possible that the Watch will open it's open subscription along with the iPhone. It's also possible that the watch will re-use the iPhone's connection.

If you only ever see 2 connections and 8 are open then there's something else going on with the ISY as detailed in your original post. This also mirrors my testing on this issue. I've never seen a case in the lab where the iPhone/MobiLinc and Apple Watch MobiLinc ends up eating all 10 slots.

Wes

[Whitehambone]

On 1/4/2021 at 6:35 PM, vspete said:

1. I appreciate the additional time associated with the 2048 bit handshake.  I accept that when using https.  It is either that or establishing a VPN connection to my Fortigate and then going http.

What FortiOS are you running?  Have you upgraded the Fortigate's firmware recently?  I have experienced many of these same issues.

[vspete]

59 minutes ago, Whitehambone said:

What FortiOS are you running?  Have you upgraded the Fortigate's firmware recently?  I have experienced many of these same issues.

I am running FortiOS v6.0.10 build0365 (GA) and haven't updated the firmware for several months. I did upgrade my ISY security cert due to its expiration. When I removed Mobilinc from my iPhone and reinstalled, it would not work with the expired cert. I created the new cert with a 2048 bit key (the old one used a 512 bit key). This is when I noticed increased delay in connecting when https was used. I have tested connecting securely connecting via both LAN and WAN. There wasn't any noticeable difference.  To my knowledge, the Fortigate only plays a role when a WAN connection is used.  I haven't noticed any performance hits with the level of FortiOS I am running.  I hope this helps.

[Whitehambone]

46 minutes ago, vspete said:

I am running FortiOS v6.0.10 build0365 (GA)

It seemed I had some similar troubles when I updated my Fortigate from 6.2.X to 6.4.X with UDP/TCP bombardment.  That why I was wonder what FortiOS you were running.  I had to do some creative networking to resolve the problem, but I never figured what caused my issues.  Most people don't run FortiGate's at home.  But I still get similar things as you are experiencing in my logs and I also use MobiLinc.  I uninstalled MobiLinc on my AppleWatch and will see what happens.

[vspete]

@Whitehambone, I run a Fortigate 60D POE at home and will be unable to upgrade the firmware beyond v6.0.xx due to hardware limitations. I think you will find that the issues are associated with the Mobilinc iWatch extension.  I have abandoned being able to use Mobilinc with iWatch totally and now have zero Mobilinc connection issues on the iPhone.

Apple has made significant security changes on iOS that have resulted in usability issues.  For example, I find using my iWatch to control my garage door opener (MyQ) or Alarm System (TC 2.0) no longer useful.  Since the last iOS upgrade, these iWatch apps regularly will not connect and show that logging into the respective accounts using the iPhone app is required prior to working. When I say regularly, I mean at least once a day and randomly. As you must retrieve the iPhone and do this step, the convenience using the iWatch App is completely lost. And the experience just serves as a frustration. I just noticed that my Powerview (Hunter Douglas Shades) will not show scenes on my iWatch. This is new, they are properly selected in the iPhone app.

Mobilinc Pro is no longer being updated by its developer, so it is what it is.  

Edited January 22, 2021 by vspete

[Whitehambone]

@vspete, I forgot to mention that I found much better HTTPS performance offloading SSL to PC running Stunnle.  It really shortens the delay to the ISY.

[vspete]

On 1/29/2021 at 5:16 AM, Whitehambone said:

@vspete, I forgot to mention that I found much better HTTPS performance offloading SSL to PC running Stunnle.  It really shortens the delay to the ISY.

Thanks @Whitehambone!  I am okay with the SSL performance as I seldom use it to access my ISY. Most accesses are from the LAN side and are not encrypted beyond the WiFi connection. My server remote desktop, security NVR, cameras, etc., all require a VPN connection through the Fortigate when accessed from the Internet.

[Geddy]

@vspete going back to your original post...have you had success with the phone/watch connecting quicker as expected? I had similar issues with the phone really being slow to connect/refresh all dashboard devices. I hadn't thought too much about it and I don't use the app as much these days, but it appears iOS 14 changed the local handling of direct connection.

@InsteonNut made a post that fixed the slowness issue I was having instantly!  

 

Now when I open the app while on my LAN the dashboard is instantly updated and when I go to sync with ISY to test it out it updates a ton faster than before I made the change. I apparently did not allow local network access when opening MobiLinc after updating to iOS 14.4, but after making the change things are much smoother and quicker to reply.

I am on Firmware 4.9 so don't have 5.x or nodeservers running so can't help with other issues you've posted about, but wanted to say if the original post of sluggish or disconnecting from the ISY while inside the LAN this could be your issue as well.

 

 

 

[vspete]

@Geddy, I was aware of the iOS privacy notification issue posted by @InsteonNut. That wasn't the issue in my case. My iPhone Mobilinc iOS connection issue was tied to the iWatch Mobilinc extension.  The iWatch extension is not usable since the iOS 14.3 update. Since that update, Apple appears to require iPhone app to be successfully authenticated to the host before the iWatch extension can be used (when host authentication is required).

Most iWatch apps (such as MyQ) require the iphone app to be logged in while the iWatch app is used. If not, the user is told by the watch that this is a requirement.  In the case of the TC2 iWatch extension, the watch provides a sign-in button on the watch.  The Mobilinc iWatch extension does not appear to recognize this change and somehow locks up both the iWatch extension and iPhone app in a condition fraught with connection issues when the iWatch extension is used.

The only solution that worked for me is to NOT install the Mobilinc iWatch extension.  When not installed, the iPhone app works just fine. Also, I haven't had any issues with my 5 node servers other than Mobilinc does not have an appropriate UI to effectively use them.  Thanks for posting your suggestion..