Texecom2mqtt: Texecom alarm panel and MQTT integration with HA support

ChrisJohnston · October 10, 2022, 10:55am

From the log trace you can see the panel is connecting fine so you shouldn’t get any UDL lockouts.

The MQTT config needs a username and password if you have set one in the mosquito add-in. Per the docs:

texecom:
    host: 192.168.0.1 # Required: Texecom panel IP address
    udl_password: "abcdef" # Optional: UDL password programmed in the panel. Note: this is NOT the code used to arm/disarm the panel (default: 1234)
    port: 10002 # Optional: port used to connect to the panel (default: 10001)

mqtt:
    host: 192.168.1.5 # Optional: broker URL or IP address (default: localhost)
    port: 1884 # Optional: broker port (default: 1883 or 8883 for TLS connections)
    prefix: texecom2mqtt # Optional: topic prefix to use (default: texecom2mqtt)
    username: my_user # Optional: broker user (default: none)
    password: my_password # Optional: broker password (default: none)
    client_id: texecom2mqtt # Optional: client ID (default: texecom2mqtt)
    keepalive: 30 # Optional: keepalive in seconds (default: 60)
    clean: true # Optional: clean session (default: true)
    retain: true # Optional: retain (default: true)
    retain_log: false # Optional: retain on log messages (default: false)
    qos: 2 # Optional: QoS (default: 0)
    ca: /cert/ca.pem # Optional: CA for TLS connection (default: none)
    cert: /cert/cert.pem # Optional: certificate for TLS connection (default: none)
    key: /cert/key.pem # Optional: private key for TLS connection (default: none)
    reject_unauthorized: true # Optional: if not false, the server certificate is verified against the list of supplied CAs. Override with caution (default: true when using TLS)

Also check to ur mosquito broker config - is require certificate enabled? If so you’ll need to add the cert/key locations

Fayrewood · October 10, 2022, 11:57am

Thanks Chris, but my Broker config is basic and no encryption set. Here’s it’s config file:

require_certificate: false
certfile: fullchain.pem
keyfile: privkey.pem
customize:
  active: false
  folder: mosquitto

I’ve removed the username and password from the Texecom2mqtt config file, but now I get a slightly different error:

2022-10-10 11:56:34 - ERROR: MQTT broker error: Connection refused: Not authorized
2022-10-10 11:56:34 - ERROR: Could not connect to MQTT broker

Fayrewood · October 10, 2022, 12:21pm

If I strip this back to basics as I may have tied myself in knots.

I have Mosquitto Broker Add On installed with the default configuration.
I cannot connect to it with MQTT Explorer unless I use the credentials of mqttuser / password which is a local user in HA. Therefore, I am assuming that the same credentials are needed in the config file for the texecom add on.
I can connect to the panel OK, but not authenticate against MQTT, which I’m starting to think is routing related and not credentials / encryption.

It may be relevant, but HA is running as a VM on Proxmox. I connect to HA via 192.168.1.144. If I go to HA’s Terminal and do an ifconfig, it reports an IP of 172.30.33.1 which is odd and not the VM bridge IP of the 192 subnet - however, I can ping 192.168.1.144 from the HA terminal which suggests the VM is routing between those subnets.

ChrisJohnston · October 10, 2022, 12:24pm

For my setup I created a homeassistant user called mqtt and used the username/password for that in the mqtt section of fhe texecom2mqtt config:

host: mqtt://core-mosquitto:1883
username: mqtt
password: *******************

ChrisJohnston · October 10, 2022, 12:26pm

Yes add the mqttuser and password to the mqtt section of your texecom2mqtt config

Fayrewood · October 10, 2022, 12:27pm

Yep, that’s basically what I’ve got (username is mqttuser).

  host: 192.168.1.28
  udl_password: "2711"
mqtt:
  host: mqtt://core-mosquitto:1883
  user: mqttuser
  password: redacted
homeassistant:
  discovery: true
areas: []
zones: []
log: debug

ChrisJohnston · October 10, 2022, 12:49pm

Couple of other things to check on your mosquito broker add on page:

Is the host name “core-mosquitto” ?
Is it started?
In the network section of the configuration is the port definitely 1883 for “normal mqtt”?

For the people/users page;

Is the mqttuser active?

RogTP · October 10, 2022, 1:31pm

If using defaults you shouldn’t need the port number. This is my working t2m config:

texecom:
  host: nnn.nnn.nnn.nnn
  udl_password: "nnnnnnn"
mqtt:
  host: mqtt://core-mosquitto
  username: texecom
  password: ******
  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

and this is my mosquito config

logins:
  - username: "!secret mqtt_nodered_username"
    password: "!secret mqtt_nodered_password"
  - username: "!secret mqtt_ring_username"
    password: "!secret mqtt_ring_password"
  - username: "!secret mqtt_zwave_username"
    password: "!secret mqtt_zwave_password"
  - username: "!secret mqtt_texecom_username"
    password: "!secret mqtt_texecom_password"
  - username: "!secret mqtt_tc_username"
    password: "!secret mqtt_tc_password"
require_certificate: false
certfile: fullchain.pem
keyfile: privkey.pem
customize:
  active: true
  folder: mosquitto
debug: false

I have some extra config in there hence the customize/active = true, but that would be irrelevant for you.

Worth checking in the mqtt logs when you start the t2m add-on to see if it is reaching it at all, you should see some sort or connection there.

The 172 ip address is one that is on the virtual switch internal to the docker container config. If were to look at the container config for the HA container then you would see that it is exposing itself on port 8123 to your 192 network.

Bear in mind when checking connectivity, that t2m and mqtt containers run isolated from the HA (and supervisor) container on different 172 ip addresses. mqtt exposes itself to the 192 network on 1883/1884/8883/8884 (I think all) by default. They will communicate with each other over the 172 network (I think that is right for t2m → mqtt). There is an HA dns resolver which the containers use which is what resolves the core-mosquitto name.

Fayrewood · October 10, 2022, 5:12pm

Thanks - that makes sense on the routing.

I have checked the broker logs and are some connections from an ‘unknown client’ - not sure if that’s MQTT Explorer or T2M add on? GivTCP seems to be quite happy and has been for weeks.

2022-10-10 18:07:42: New connection from 172.30.32.1:52443 on port 1883.
2022-10-10 18:07:43: Client closed its connection.
2022-10-10 18:07:43: New connection from 172.30.32.1:46133 on port 1883.
2022-10-10 18:07:43: New client connected from 172.30.32.1:46133 as GivEnergy_GivTCP_1 (p2, c1, k60, u’mqttuser’).
2022-10-10 18:07:43: Client GivEnergy_GivTCP_1 disconnected.
2022-10-10 18:07:54: New connection from 172.30.32.1:60193 on port 1883.
2022-10-10 18:07:55: Client closed its connection.
2022-10-10 18:07:55: New connection from 172.30.32.1:40547 on port 1883.
2022-10-10 18:07:55: New client connected from 172.30.32.1:40547 as GivEnergy_GivTCP_1 (p2, c1, k60, u’mqttuser’).
2022-10-10 18:07:55: Client GivEnergy_GivTCP_1 disconnected.
2022-10-10 18:08:06: New connection from 172.30.32.1:33995 on port 1883.
2022-10-10 18:08:07: Client closed its connection.

Here’s my Broker Config:

logins:
  - username: mqttuser
    password: redacted
require_certificate: false
certfile: fullchain.pem
keyfile: privkey.pem
customize:
  active: false
  folder: mosquitto

and here’s my T2M Config:

  host: 192.168.1.28
  udl_password: "2711"
mqtt:
  host: mqtt://core-mosquitto
  user: mqttuser
  password: redacted
  client_id: texecom2mqtt
  keepalive: 30
homeassistant:
  discovery: true
areas: []
zones: []
log: debug

Fayrewood · October 10, 2022, 5:29pm

Thanks Chris,

Yes, the port is correct and the user is active. See logs a couple of posts up - the mqttuser account is working ok on 1883 for GivTCP.

RogTP · October 10, 2022, 5:37pm

You should see t2m client_id in the mqtt logs. That said mqtt logs seem to run behind or something. There will be an unknown client connect that repetitively fails, this is the supervisor checking if it is alive, it can be ignored.

Fayrewood · October 10, 2022, 5:37pm

I’ve noticed that there’s a one hour time difference in the logs… could this be causing a problem? T2M is an hour behind, whereas MQTT Broker shows the correct time.

RogTP · October 10, 2022, 5:44pm

Might be worth turning on debug logging in mqtt, you can see it turned off in my config.

Fayrewood · October 10, 2022, 5:55pm

Interesting… Debug turned on but absolutely nothing from t2m client_id in the logs. plenty of ACL checks for mqttuser, but that all looks OK and GivTCP uses the same account and that’s OK.

It’s suggesting routing as the problem, but if I use the mqtt user credentials on my mac with the HA VM IP, it connects fine. I’ve tried replacing core-mosquitto with the IP address as well, but it still fails.

Stumped…

RogTP · October 10, 2022, 6:19pm

Do you have any areas/zones configured. Not sure when t2m tried to connect to mqtt. Maybe only after it knows it has something to pass.

This is my t2m log, you can see when it comments to mqtt. Do you see the connection trying to happen?

2022-10-10 17:47:49 - INFO: Starting texecom2mqtt v1.2.3 (Node v16.13.0)…
2022-10-10 17:47:49 - INFO: Connected to alarm, sleeping for 2 seconds…
2022-10-10 17:47:52 - INFO: Connection ready
2022-10-10 17:47:52 - INFO: Logging in to panel
2022-10-10 17:47:52 - INFO: Successfully logged in to panel
2022-10-10 17:47:52 - INFO: Connected to MQTT broker: core-mosquitto:1883 (retain: true, clean: true, client_id: texecom2mqtt, qos: 0)
2022-10-10 17:47:52 - INFO: Serial number: 1003728
2022-10-10 17:47:53 - INFO: Panel: Premier Elite 12 (V6.02.02LS1)

RogTP · October 10, 2022, 6:20pm

By the way, what type of install are you using? Hassio OS, supervised, or ?

Fayrewood · October 11, 2022, 5:02pm

I haven’t set any zones to try and keep everything simple.

I believe that I cannot connect due to an authentication issue. If I set the mqttuser to something wrong, then the connection very quickly fails with ‘Not Authenticated’, however, with the correct credentials, it seems to loop for a minute before erroring with ‘ERROR: Could not connect to MQTT broker’.

Weirdly the same credentials work fine in MQTT explorer, so it’s localised to the HA installation, which is hassio on ProxMox VM.

RogTP · October 11, 2022, 5:17pm

From the configs I’ve provided you can see how to add extra users in mqtt to use in t2m.

Fayrewood · October 11, 2022, 7:20pm

Thanks Roger - I’ve been through your config again and have set up two users. Thank you for your time and patience.

mqttuser1
mqttuser2

If I set the user in the T2M add on to either of these in the GivTCP plug in, connection to MQTT broker works fine, so the ACL and permissions are fine.

However, if I user either of the users in the T2M Add On, it still fails with no logs in MQTT Broker. I have stopped the GivTCP Add On so that the only add on trying to connect to MQTT broker is T2M, but it still fails to connect.

This is driving me nuts now as it defies logic. Any more ideas gratefully received.

RogTP · October 11, 2022, 7:42pm

To be honest I use Portainer on a separate box against a Supervised install rather than a Hass OS install. This would allow me to get into a terminal session and try to ping the mqtt container from the t2m one to see if it is accessible. But since you have hass os, it would be a challenge to give Portainer access to your docker setup (which is what is used in HA installs).

That said, you said that you said if you use an invalid user it shows an failed login, so I really don’t understand why it is failing. Again it could be because it has nothing to pass to HA because you have no zones configured.

I’m begginning to lose it in this. Have you tried setting t2m to debug logging?