Could you elaborate a bit further on what you’ve done to get this working, so that I may follow it?
Not a texecom expert, but technically savvy.
Thanks
Assuming you have plugged your Smartcom into com ports 1 &2, you need to plug Texecom Elite ComPort+ into the digi modem port of the alarm, this creates a third com port. Then plug the Com-IP or Com-Wifi into the ComPort+ and configure it up. You will then have two devices connected to your home network. Leave the Smartcom to communicate with Texecom, and use the other com device for your HA server to talk to.
I have 5 of the ComPort+ because they are dead cheap and they came in a box of 5. Only to find my installer had already put one on the board and hadn’t been able to configure it correctly. Quickly fixed, and all works fine.
Ah brillaint ok thanks
Yes, SmartCom is in Com1+2.
I will need Wifi as theres no wired ethernet at my panel.
However, just to be clear I understand the situation… If i can integrate with HA then I dont think i need the Texecom Mobile App. If I uninstall all connected instances, do I still need your described hardware workaround? Will HA have a stable connection then? That way I dont need anything…
Thanks
You will of course need the Smartcom or Com-Wifi for HA to talk to, not sure what you mean by all hardware.
Smartcom will naturally want to talk back to Texecom, which I imagine you can stop, I think there has been conversation on here about it. If you don’t want that, then I don’t think you need anything other than the smartcom. You will need to stop Texecom2mqtt when you want to do configuration via wintex.
As for stable, I have found neither Smartcom or Com-Wifi to be 100% stable. I’ve had to reconfigure both in the last months, but I guess that makes no odds whether you use the app or HA to control.
Funnily, I still get lockups even now, where the integration is “dead” but only seems to realise when you try to interact with it (e.g. set the alarm). I have a single SmartCom with the core Texecom services disabled on it, but it still seems to want to chat back on its own and I wonder if this is causing conflicts on something that is effectively just a glorified null-modem cable.
I’ve ordered a Com-IP module so will configure that on Com3 (found the Com+ adapter buried on my desk!) and will repoint HA at this to see if it behaves any better.
I will report back once it turns up and I have tried it.
I don’t get lockups, but because I get occasional connection losses on key components (Hue, Texecom, Internet, etc), I ping them on a regular basis so I get some forewarning. So I know the Com-Wifi link goes down occasionally for longer than 60 secs (the timeout I have on my ping checking). It usually come up again pretty quick, but I did have to reset it up for the first time in months a in early October. Previously it has run steady for many months.
That said, the info I get from the Ricochet PIR is rubbish. Doors opening and closing is spot on, but the PIR doesn’t bear any resemblance to the reality of motion in front of it (it misses loads). But then, the motion is at times when the Alarm is switched off so maybe it just pools occasionally. I need to to a walk test to see if it is reliable when alarm is set.
Apologies, what I mean is I’ll need to buy the ComPort+ and ComWifi if the hardware route is necessary - ideally I’d avoid this.
I’ve uninstalled the Texecom app from my phones but I’m still seeing regular periodic unavailability - if this is the single connection issue, is there somewhere I can see whats going on - e.g. connection logs to see if theres a 3rd device stealing connections
Thanks
Sorry I can’t help with any logging on the alarm, I know some others on here have done detailed work, so maybe they can give details.
Even if you disable ARC (Alarm Receiving Centre) on the alarm, it still tries to talk to Texecom.
I have a Security VLAN, for cameras and SmartCOM, it has no internet access generally.
I know the person I was discussing with above, I think, resolved their random issues with firmware.
It was me, probably. Sadly the SmartCom firmware update didn’t fix things - it was better afterwards but I still get periods where the add-on fails and isn’t picked up / restarted by the watchdog. My Com-IP is on order, so we’ll see if segregating the HA traffic helps things.
Have you tried null-routing - or if you have one - simply blocking on the firewall, the SmartCOM?
Have you tried to set them to always alive? Door contacts usually are, I think.
I know this is against their best practise, but I found it actually improved the reliability of my Ricochet network no end - I’m sure I read on some random forum somewhere, that it was recommended (but against the documentation) by some Texecom engineers, with certain PIRs, I forget all the details but gave it a shot and it helped.
I have a couple of mini battery door contacts, without the contacts, that I just use as ricochet repeaters.
I’ll take a look at that, just need to find in Wintex.
Auto Mode
Auto Mode is the default device setting for the Premier Elite XT-W QD-W when used on V1 systems.
When in Auto Mode, devices poll at 15 minute intervals. Following activation, devices will not
transmit the same activation again for a period of 3 minutes.
Always Awake
This mode should only be used on devices which are required to signal at all times and is the default
setting for the Impaq Contact-W and Impaq Plus-W. For example a Impaq Contac-W on a door
which you need to know is opened, regardless of system state; or device
From memory it was a drop down, where the default is usually ‘Auto Mode’
I have a DT-W and reading this System Devices; Auto Mode; Always Awake; Hybrid Mode (Ricochet Mt2 Only) - Texecom Premier Elite 8XP-W Installation Manual [Page 46] | ManualsLib it should always be in Hybrid otherwise it will knacker the batteries. Shame, may look at an alternate.
A battery device ultimately is a battery device, with battery limitations. But it depends if you want it to always alert, which is going to use more battery… or not… I think? 
Personally I change all my Z-Wave batteries once a year anyway, regardless of whether it says they need changing or not, and they easily last a year. I also do the same with the alarm batteries.
Good to know, I’ll give it a try. Do you know a way of monitoring the batteries on Ricochet devices without going into the Ricochet app?
Well Always Awake had the effect of causing my alarm panel to chirp, and alert me that the battery was dead…
1 Like
I don’t - I had been meaning to ask if it is/was going to be possible to add it to this integration.
Over the years I was bitten many times by ‘almost dead’ batteries, caused havoc with some Lightwave-RF MoodSwitch devices, where they seemed to ‘spam’ the radio frequency, causing other devices with full batteries to not be able to transmit on ‘clean’ radio space.
So, I just change all batteries, once a year, regardless. Never had any problems since with battery devices.
Looking at this some more, I think the add-on exposes an event to HASS via MQTT. There is a list of available events on the info page of the add-on. So I think it should be possible to catch the event. It would however be good if the battery info was exposed as a battery sensor. I’ve not successfully listened to them yet, but I’ll continue to play.