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 
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?
I have successfully installed the Texecom2mqtt add on into my HA pi, and can see successfully connectivity to my premier elite 48 panel in the log, however I’m not getting anything appear in Ha itself, on the configuration tab in texecom2mqtt this is the yams export, am I missing something?
texecom:
host: 192.168.10.32
udl_password: "1234”
port: 10001
mqtt:
host: mqtt://core-mosquitto:1883
port: 1883
prefix: texecom2mqtt
username: mqqtt
password: mqqtt
client_id: texecom2mqtt
keepalive: 30
clean: true
retain: true
retain_log: false
qos: 2
reject_unauthorized: true
discovery: true
homeassistant:
discovery: true
prefix: home-assistant
areas:
- id: house
name: House Alarm
full_arm: armed_away
part_arm_1: armed_night
part_arm_2: armed_home
part_arm_3: armed_custom_bypass
code_arm_required: true
code_disarm_required: true
code: "8795"
- id: ...
name: ...
zones:
- id: front_door
name: Front Door Sensor
device_class: motion
- id: ...
name: ...
cache: true
log: debug
Are you seeing something like this in your log?:
2022-09-13 19:40:19 - INFO: Connected to MQTT broker: core-mosquitto:1883 (retain: true, clean: true, client_id: texecom2mqtt, qos: 0)
My working config looks like this:
texecom:
host: redacted
udl_password: " redacted91"
mqtt:
host: mqtt://core-mosquitto
username: redacted
password: redacted
client_id: texecom2mqtt
keepalive: 30
homeassistant:
discovery: true
areas:
- id: house
full_arm: armed_away
part_arm_1: armed_home
zones:
- id: inner_doors
device_class: door
- id: external_bell
device_class: sound
log: info
You have 1883 as port both in the host part as well as port part.
In the username/password part you state ‘mqqtt’ Is this correct? (if you use authentication)
Have you looked at the broker? (e.g MQTT Explorer)
Well spotted mrhass, I have removed from the host section and it still connects fine. Yes I created a new mqqtt user with admin role and will change once I have it up and running. Mqqt explorer I haven’t got that installed.
Yes that is in the log:
2022-09-14 13:58:45 - INFO: Starting texecom2mqtt v1.2.3 (Node v16.13.0)...
2022-09-14 13:58:45 - INFO: Connected to alarm, sleeping for 2 seconds...
2022-09-14 13:58:47 - DEBUG: Executing serial number command
2022-09-14 13:58:47 - INFO: Connection ready
2022-09-14 13:58:47 - INFO: Logging in to panel
2022-09-14 13:58:47 - INFO: Successfully logged in to panel
2022-09-14 13:58:49 - INFO: Connected to MQTT broker: core-mosquitto:1883 (retain: true, clean: true, client_id: texecom2mqtt, qos: 2)
I can see it’s connected fine to my control panel, it lists all the zones, devices etc in the log but what do I do next I thought as I have discovery on it would simply put all in to Ha. What do I do next?
You don’t need to do anything else, there should be a single device named after your alarm model (eg Texecom Premier Elite 64).
I think probably your prefix’s need to be the same between mqtt and homeassistant. I don’t have those parameters and it works fine.
I think home assistant mqtt broker is listening for ‘homeassistant’. I would suggest getting mqtt explorer and see what you are publishing.
MQTT autodiscovery in Hass is default set to the ‘homeassistant’ topic, so in the config it’s set to “home-assistant” which won’t work with default settings.