My HA system using WiFi, Zigbee devices and the excellent Texecom “Ricochet” mesh devices. I can use all three in my HA system. The Texceom “Ricochet” devices seem to have a much greater range than ZIgbee or WiFi and using Ricochet devices means I have no wires for HA or the Texecom.
Considering ricochet to extend my system. How easy are they to install?
Very easy for me as my Texecom is an Elite 64 system board that has Ricochet on-board already. I am in an old house with thick “cob” walls and some solid stone floors so I ripped out the old “surface wired” messy alarm and replaced it with the completely wire-free Texecom. It also has capability of taking hard-wired inputs/outputs but even my outside siren/alarm is “Ricochet”. The sensors are not cheap but they have all proved exceedingly reliable and when the integration with Home Assistant arrived, I was over the moon! The integration is very smooth and I have the Smartcom link to my PC via wi-fi using the Texecom Wintek app to configure/administer the Texecom system as it also has the Ricochet smoke, fire and Carbon Monoxide sensors whichhave built in sounders that all sound if any one detects something amiss. I’ve had the system for around 2 years and not had to replace a battery yet in any of the sensors.
Does anyone know if we can get the user who armed or disarmed the system?
I have had a look in the MQTT topics and can’t see any user data anywhere, is this info available anywhere as I note the logs accessible via the Texecom app show this info.
Sorry if this has been covered, I did scan the above but it’s a pretty long thread so may have missed it
Nathan.searle1 asked a similar question about 18 or 20 posts above yours, which I had a go at answering in the next couple of posts. HTH.
1 Like
Perfect, thank you.
Have changed the log level and can now see the relevant info in the addon logs but I don’t (well haven’t as yet) use nodered.
Maybe time to look into nodered, is this going to be the only way to get that info in to home assistant for the time being so you know?
No, there are other ways to get mqqt information into HA.
1 Like
Managed to get it working after lots of messing around, as i didnt realise this only works if using a code via the keypad and does not appear to expose the prox tag info and as we only use prox tags I am now thinking it wont be possible.
{
"type": "ProxTag",
"description": "Prox Tag",
"timestamp": "2022-08-05T07:54:24Z",
"areas": [
"A"
],
"parameter": 1,
"groupType": 0
}
Yeah, we mostly use either the Texecom app or Home Assistant so it’s not a great lot of use for us either. Nice to know it can be done, though.
Agree with the advice to swap the panel for an Elite one. The cost really is minimal. I found myself in a similar position and went this route. I prefer the robustness of a separate dedicated alarm system and the Texecom panels are rock solid and easy enough to configure with the software. Texecom support and forums are also helpful.
The HA integration via texecom2mqtt is excellent and I use the sensors attached to the alarm to trigger automations in HA. Remote arm/disarm is also useful.
Tom
HI all… this is an excellent integration for my HA. What I have noticed since I added Texecom to HA, previously, when ever we set or disarmed the alarm, we used to instantly get notifican on our Texecom app on our phone at what activity took place. However, what I am finding now, is that we will get these messages queued up and then receive them at a point where we get all messages in one go. Has anyone else experinced this?? If so, is there a resolution to this??
I can’t comment on your specific case as I don’t use the Texecom app, but the ComIP interface is pretty basic really - it’s effectively a serial port run over IP - and it does not handle multiple connections at all well. If you’re using a single ComIP to do both Home Assistant and Texecom Cloud, then you’re going to get weird stuff like this happening I’m afraid.
Personally speaking, I have two ComIPs in my alarm - one dedicated to HA, and the other now only used for Wintex or the occasional used of Texecom Cloud for doing firmware updates. This saves me from having to stop the HA add-on if I want to do any other management of the alarm. In your case, I would certainly recommend going down this route if it’s an option for you. I picked up my spare ComIP on eBay and there’s a few on there going cheap right now 
3 Likes
Thanks… sounds very much like it… I will ask my alarm installer to see if I can add additional ComIP as it is under warranty.
Has anyone else noticed some odd behaviour recently with the addon dying? I think it’s crashing as often as it used to, but for some reason HA doesn’t seem to be restarting it. “Watchdog” is still ticked, but it just says “the add-on is stopped” and I have to click start again myself. Perhaps this started with 2022.8?
The log is just stuck on “Panel disconnected, exiting now” which I’m assuming used to happen semi-regularly but I didn’t know because HA was restarting the addon properly…
Answering my own question - Add on not automatically restarting
22-08-13 21:10:56 WARNING (MainThread) [supervisor.addons.addon] Watchdog found addon texecom2mqtt is failed, restarting...
22-08-13 21:10:56 INFO (SyncWorker_4) [supervisor.docker.interface] Cleaning addon_c15a2434_texecom2mqtt application
22-08-13 21:10:57 INFO (SyncWorker_5) [supervisor.docker.addon] Starting Docker add-on dchesterton/texecom2mqtt with version None
22-08-13 21:11:01 ERROR (MainThread) [asyncio] Task exception was never retrieved
future: <Task finished name='Task-116212' coro=<Addon.watchdog_container() done, defined at /usr/src/supervisor/supervisor/addons/addon.py:959> exception=AddonsJobError('Rate limit exceeded, more then 10 calls in 0:30:00')>
Traceback (most recent call last):
File "/usr/src/supervisor/supervisor/addons/addon.py", line 965, in watchdog_container
await self._restart_after_problem(self, event.state)
File "/usr/src/supervisor/supervisor/jobs/decorator.py", line 129, in wrapper
raise on_condition(
supervisor.exceptions.AddonsJobError: Rate limit exceeded, more then 10 calls in 0:30:00
It is easy to wire up a Shelly UNI to a zone in the alarm and then control the Shelly UNI from Home Assistant to activate the alarm. The Shelly UNI can also take its 12v supply from the alarm.
Yeah, I’ll probably just use an ESP module as I’m comfortable working with them, but this definitely seems the way to go for this. On my list of things to do when I get a few minutes…
Hi
I am on 2022.8.4 with a Premier Elite 48 panel on Firmware: V5.02.01LS1
Sorry - this probably isn’t helpful but my experience is that the integration is stable. I haven’t noticed any crashes this year and my logs look clear.
I use HA to check the status of the alarm remotely and also exploit the alarm sensors for automations so do notice if something breaks.
I have a dedicated connection from the panel to HA via a Com-IP as I understand that Texecom doesn’t really like sharing ports.
Kind regards,
Tom
Thanks, I’ve been getting by just fine sharing with the Connect (I guess not noticing that occasionally the addon was losing connection but restarting) but it sounds like it’s time I finally got a COM-IP…
Hi, were you able to you fix this problem… I’ve noticed I’m having the same symptoms.
Logs show the following:
2022-08-22 17:06:27 - ERROR: Corrupt response from panel: CRC 253 is invalid (message: 744d0846195700fd)
2022-08-22 17:06:27 - INFO: Panel disconnected, exiting now
In my case when I hit the start button, the app starts to run, but the status of texecom2mqtt stays red (you know red blob in the top right corner of the app).
Did you observe anything similar?