Further to my previous post I thought I'd also mention some considerations when deciding to implement ComNav.
Cloud based service
The ComNav communicates with a cloud based service to send alert reports. Unfortunately there is no ability to configure the ComNav not to use the cloud service, which is what I would have preferred. This means you are dependent on the cloud service provider to continue to provide and maintain the service. There is very little visibility on what this service is. See
App history and support
The current app is UltraSync+, was UltraConnect and before then was xConnect. If you read through the reviews of the UltraSync+ app there were periods of dissatisfaction including a review in Jan 2022 saying it was abandoned because the company went out of business in 2019 with effectively no support from Dec 2021. All before my time but it seems to be working fine now.
App unreliability
I found alerts sent to the app to be unreliable. I'm using version 2.21 on Android. I suspect it has a lot to do with the state of the app on my phone. Setting the app battery optimisation to Not optimised did not help. If an alert notification was sent after I have recently opened the app, then I would get it. However if I did the test a few hours later I would not get it. Despite the app not reliably getting notifications, I always receive alarm reports sent to my email.
Alert report delays
I have had the ComNav working for just over 6 weeks and have noticed occasional delays in receiving alarm reports in my email. My alarm panel does a daily test early in the morning and I've noticed that on 6 occasions that report got to me up to 3 hours later. No particular pattern nor can I replicate it at will. Furthermore, whenever I do any test it delivers the alarm report within a minute. When examining the email headers it seems it uses Mandrill, which is now part of Mailchimp. Both are a mass email delivery platforms but in general Mandrill is used for transactional emails while Mailchip is used for email marketing. From the headers the issue seems to be with the ComNav cloud service provider not Mandrill.
Best practice for secure ComNav deployment
I have already mentioned in the earlier post about security vulnerabilities in earlier versions of ComNav. This is why I restrict the ComNav and all my other Internet of Things (IOT) devices on what they can do. I keep IOT devices (e.g. smart light bulbs, TVs etc) on their own DMZ (segregated network), away from my main network. The reason for doing this is that if an IOT device is compromised any damage can be contained. IOT devices are not like your PCs and smartphones that get regular updates. Furthermore, any update that may be available might not be easily applied, let alone automatically. ComNav is a perfect example of that. IOT devices are typically low cost (especially compared to PCs and smartphones), which means maintenance (particularly security maintenance) on such devices is frequently a low priority. It comes down to economics. Should a vendor spend money on updates for a $30 smart powerboard or $15 smart light bulb which appears to be working fine, or do they use the money to add more features and capabilities to the product to sell more of them?
I put the ComNav its own dedicated DMZ with nothing else so that I can also ensure that its traffic has priority over everything else. As I wanted to restrict what it can do I examined which cloud service it connects to. When checking the DNS records it connects to zerowire (specifically s1.zerowire.com and s2.zerowire.com) on port 443 and the IP address indicates the service is hosted on Amazon AWS. Like ComNav and the Hills Reliance (Interlogix NetworX) alarm panels, Zerowire is owned by the Carrier Corporation. I have configured my firewall to strictly restrict traffic from the ComNav to zerowire on port 443.
I know most households would not know how to implement DMZs, but I've started to see standard home routers/modems come out pre-configured with multiple networks, allowing you to isloate certain networks for Guest Wifi or even IOT. It seems the need is generally recognised and vendors are trying to find ways to make it easy to implement. I suspect most would probably not use this feature even if available but if you have the expertise and your network equipment can do it, I recommend you do so.
Z
Bookmarks