Texecom ComWifi - is it really this terrible?

[jdp80]

I'm setting up a Premier Elite 48 with ComWifi and I'm really disappointed at how bad the whole notifications/remote management side of things are.
In fairness it's good for setting up the alarm, but I could just use USB.

The mobile app is truly dreadful. A mess of failing connections, lag on key inputs, randomly failing to work.. Do Texecom expect end users to use this? Even on the local network it's slow. Compared to even a simple app like Evohome it's prehistoric.

The notifications are really unreliable, some don't arrive, others take 20 minutes to arrive, with no real pattern as to why (the wifi link is monitored and never drops).

I had hoped for a nice simple app I could install on mine and the missus' phones to alert us when an alarm goes off, perhaps set the alarm if we forget when we go out, but my house would probably be ransacked by the time I received the notification :S

I hope Texecom Connect improves things, but I'm regretting not just sticking with the USB connector and a com GSM.

Anyone use it day to day and find it useful?

 

[GalaxyGuy]

It's a bit concerning that they are jumping to a whole new level of complexity with the connect service after failing to get the simpler push notificaton to an acceptable standard of service.

 

[secureiam]

Think that's an issue to take up with Texecom.

does it work on com wifi/com ip, gsm over gprs the answer is yes and they appear to be as reliable as each other.

new panel firmware has supposed to address the com port fault issue, but no confirmation on it resolving missed notifications.

 

[jdp80]

Unfortunately this morning I got a COM port error for ten minutes, which generated a fault.

I doubt it's my network, it has a static IP outside the DHCP pool and the panel is close to the router.

Did you get a chance to try 3.02, does it fix it?

I'm tempted to fit a ComGSM instead, I know SMS isn't guaranteed but it must be more reliable than this .. I see on the Texecom forum that their testing reveals 90% of notifications get through - not good.

 

[Nintendofan]

Unfortunately this morning I got a COM port error for ten minutes, which generated a fault.

I doubt it's my network, it has a static IP outside the DHCP pool and the panel is close to the router.

Did you get a chance to try 3.02, does it fix it?

I'm tempted to fit a ComGSM instead, I know SMS isn't guaranteed but it must be more reliable than this .. I see on the Texecom forum that their testing reveals 90% of notifications get through - not good.

Get a 3rd party GSM voice dialler activated from the bell outputs, best of both world then.

 

[secureiam]

WRT to reliability of the notifications getting through I haven't noticed any benefit, its too early to tell regarding 3.02 and the comport fault however none as yet on multipul systems.

I am undergoing several tests at the moment and Texecom are making changes to improve things whilst they say this is happening it does take time, they are adding new servers and fine tuning things.

 

[ultomoat]

GalaxyGuy: Have you thought about making Selfmon for Texecom? Given how unreliable their own offering is there must be a market for it. And Texecom will provide the protocol.

 

[jdp80]

It's a shame, because the other parts of the system seem very well designed, and they're much more complex than whatever the ComWIFI does.
I'm sure they have the technical capability to design a proper IP based reporting system, maybe there isn't much call for it, coming between simple unmonitored installs and fully monitored systems with ARC etc.


Let's wait and see what Texecom Connect brings.

 

[secureiam]

@jdp80 things are a foot, there have been issues with many of these reporting systems by many manufacturers.

Some of which appear to have got things sorted ish and others that haven't yet.

Having discussed this matter with Texecom specifically, the comip and com wifi are not necessarily the only issue involved.
its way more complex if I believe everything I have been told. Whilst I remain unconvinced on somethings I have been told one has to act on the information as they have done the testing.

I will know more once the new servers are up and running and available, I am unconvinced at the moment Texecom connect will resove the notifications issue at present, I will certainly feel more omfortable when they get the current notifications back to how it was in the earlier days of the app notifications and several issues have been addressed but time will tell if they have been truly fixed.

Risco also had a lot of issues with the cloud service and now its relatively very stable (touch wood), but it wasn't without its issues that is for sure. Certainly put a few installers I know off the product.

 

[GalaxyGuy]

I did write a receiver module for the Texecom, but I didn't like the way their protocol implementation would compromise the SelfMon platform. I could probably implement some workarounds, but didn't think there would be enough interest.

The main issue at play is that these systems all have firmware foundations with old serial protocols and the IP based devices have been bolted on many years later. We really could do with a new technology company to come in and blow all this apart. An open source control panel implementing all the standards would be ideal. Kickstarter anyone?

 

[secureiam]

Orisec lol?

I don't know about enough interest, but what would it offer?

Compromise?

sometimes to innovate starting from scratch is best, rather than tweaking the existing.
My understanding is nothing fundamnentally has changed for years with the protocols just additional bits added.

 

[GalaxyGuy]

Orisec lol?

I don't know about enough interest, but what would it offer?

Compromise?

sometimes to innovate starting from scratch is best, rather than tweaking the existing.
My understanding is nothing fundamnentally has changed for years with the protocols just additional bits added.

The compromise is mainly with plain text transmissions and client identification. The app introduced a basic optional end to end encryption, but did nothing for ATS.

Orisec products aren't open-source firmware and they don't look very good either. In the days of the sleek iPhone and tablet devices, 'installed' alarm products look at least 15 years behind. My thoughts are that we need to take the current enclosures like the Texe or Honeywell and create an open-source multi-zone capable main board to retrofit what we have today. The design would have decent ARM CPU's and support concurrent real time and shared time operating systems to provide all the features of current systems, coupled with the extensive functionality of current mainstream OS offerings. Drivers could be written to use all the best peripherals available to the current systems in today's markets. An open source design would allow for standard builds for the professional install, while allowing forking for home automation and other implementations. I would and could do all this, but I would need help, as time is the main obstacle for me.

 

[jdp80]

Stuff like Nest and Evohome have shaken up what was quite a static market for a very long time, so I have no doubt alarm systems could go the same way.
It surprised me to find that 'comwifi' was so low tech in how it interacts with the board, I had expected something a bit more integrated when I purchased it, especially on the app side.

Perhaps add a middle layer between the alarm hardware and notification framework, so that the existing (proven) alarm hardware could run without changes, then hand off all interactions to a separate module, which could utilise multiple paths to a notification system in "the cloud" ..

 

[GalaxyGuy]

Stuff like Nest and Evohome have shaken up what was quite a static market for a very long time, so I have no doubt alarm systems could go the same way.
It surprised me to find that 'comwifi' was so low tech in how it interacts with the board, I had expected something a bit more integrated when I purchased it, especially on the app side.

Perhaps add a middle layer between the alarm hardware and notification framework, so that the existing (proven) alarm hardware could run without changes, then hand off all interactions to a separate module, which could utilise multiple paths to a notification system in "the cloud" ..

With retaining the current main host processor, there's always the compromise of its capability and being limited to what the manufacturer will provide. I do agree that there needs to be a split between the real-time alarm functionality and the non critical functions, that's why I mentioned the two systems running independently and yes, they would be bridged, but not by some slow protocol as in current systems, but by DMA. I think that it would be important to have open source of the main security components of such a system, as closing it down would limit the functionality and flexibility.

The reason I say the above, is that I have already designed devices to bridge current Honeywell Galaxy and Texecom systems. The devices emulate peripherals and receive the event information themselves, but they are always limited to what the main CPU can offer and the time in which it will provide the information. This restricts the design and it always ends up being driven or limited by the original manufacturer. In any situation that there is a bug in any data passing mechanism, then you're at the mercy of the equipment manufacturer.

I think it's possible to re-create the main CPU component of such systems and make it much better. As I hinted earlier, there's nothing to stop the system devices being the same as they are today. You could have a Galaxy keypad and a Texecom Ricochet wireless mesh receiver network.

 

[secureiam]

obviously brighter than me.

end of the day you are making the data readable on both systems in some way and relay it back ib the way it understands?

a translator/????


or do I misunderstand it on even the most basic terms.