Texecom2mqtt: Texecom alarm panel and MQTT integration with HA support

dchesterton · January 25, 2021, 11:44pm

The app only receives the zone type from the Texecom API so it has to try and guess the type of device based on that. If it can’t work it out, it defaults to motion which I think is what’s happening here.

You can override the device class manually e.g.

homeassistant:
  zones:
    # This can either be the zone number or the name of the zone lowercased and with spaces replaced by
    # underscores (e.g. Front Door = front_door)
    front_door:
      device_class: "door" # or "vibration" etc.

Out of interest, which zone type do you have this configured as?

greghesp · January 25, 2021, 11:47pm

Hmm I’d have to double check.
Looking in the texecom app, it’s down as a shock sensor (with reed switch add-on) as it’s not just the motion sensor.

Will try the override

dchesterton · January 25, 2021, 11:50pm

Hi David,

I think you might be the first to test with a Elite 640! The Texecom API differs quite a bit between the 640 and the smaller panels due to the additional areas etc. I’ve tried to handle the differences but it’s difficult without access to a panel and I think you might be running into a few bugs.

Can you post the full log from starting the app to getting the RangeError and I’ll see if I can figure out what’s wrong?

greghesp · January 26, 2021, 11:27am

OK, the Kitchen Window for example shows up in HA as Open/Closed, however it is a Shock sensor. Wintex see’s it as so:

The patio doors are also Shock Sensors, but they have a reed switch on them too:

My other doors though are showing as Entry/Exit zones with a Contact device type. The reason I used a Shock with reed switch for the patio doors is they’re also giant windows

BestGear · January 26, 2021, 3:20pm

Thanks Daniel

I will do that tonight and report back. Is there an easy way to access the whole texecom2mqtt log rather than trying to capture the text from the GUI? Can I add a file attachment or do I paste *all& the log entries in the body of my reply? (sorry for being thick here…).

I use a 640 for a few reasons - I connect alarm devices in one Area and HA monitored devices in another. The 640 has 8 networks, which allows range and a number of expanders on each network and the networks head off to different areas of my home. I have a good number of HA devices connected to expander, hence the capacity for a load of non-alarm zones.

Out of interest, the 640 only had support added by the Connect app in v2.0 - previous versions did not work - so clearly big enough differences to matter.

Thanks for your help - speak soon.

David

dchesterton · January 26, 2021, 5:37pm

It seems Wintex gets more information from the panel regarding the Device Type but I can’t see this documented anywhere. As I say, you should be able to manually override the device_class for any of the sensors. The full list of HA device classes is here: https://www.home-assistant.io/integrations/binary_sensor/#device-class

MortenVinding · January 27, 2021, 10:41am

sorry did not se your reply.

you absolutely should be able to connect to it using Wintex.
What serial adapter are you using?

I found most of the information I used here: https://gw0udm.wordpress.com/2015/04/16/texecom-com-ip-controller-diy-and-cheap-too/#comments

devotee101 · February 1, 2021, 1:32pm

Hi @dchesterton - I’m getting the same error as mr6880 and Ben.S with a 64-W panel, My error reports a slightly different line number but I’m assuming that’s due to a more recent release, maybe?

I’m running firmware v5.01, connecting to the panel via a “homemade” COM-IP controller like the one detailed in this post.
Wintex all works fine, but I get the error below when I run in HA or a local docker file.

2021-02-01 13:19:24 - INFO: Connected to alarm, sleeping for 0.5 seconds...
2021-02-01 13:19:25 - INFO: Connection ready
2021-02-01 13:19:25 - DEBUG: Executing serial number command
2021-02-01 13:19:25 - DEBUG: Received data true
2021-02-01 13:19:25 - INFO: Fetched serial number: XXXXXXX
2021-02-01 13:19:25 - INFO: Logging in
2021-02-01 13:19:25 - DEBUG: Executing command 1
2021-02-01 13:19:25 - DEBUG: Received data true
2021-02-01 13:19:25 - INFO: Successfully logged in
2021-02-01 13:19:25 - DEBUG: Publishing to texecom2mqtt/XXXXXXX/status: online
2021-02-01 13:19:25 - INFO: Connected to MQTT
2021-02-01 13:19:25 - DEBUG: Executing command 22
2021-02-01 13:19:26 - DEBUG: Received data true
/snapshot/app/dist/texecom/texecom.js:83
            throw new Error(`Expected length to be ${expectedLength}, got ${thisMessage.length}, buffer: ${data}`);
            ^

Error: Expected length to be 38, got 8, buffer: tR&Eli
    at Texecom.parseBuffer (/snapshot/app/dist/texecom/texecom.js:83:19)
    at Socket.<anonymous> (/snapshot/app/dist/texecom/texecom.js:243:26)
    at Socket.emit (events.js:315:20)
    at addChunk (_stream_readable.js:295:12)
    at readableAddChunk (_stream_readable.js:271:9)
    at Socket.Readable.push (_stream_readable.js:212:10)
    at TCP.onStreamRead (internal/stream_base_commons.js:186:23)

Config is as follows:

texecom:
  host: 192.168.1.14
  udl_password: '1234'
mqtt:
  host: 'mqtt://diskstation.local:1883'
homeassistant:
  discovery: true
  areas:
    house:
      mapping:
        full_arm: armed_away
        part_arm_1: armed_night
        part_arm_2: armed_home
    shed:
      mapping:
        full_arm: armed_away
        part_arm_1: armed_night
        part_arm_2: armed_home
log: 0

Thanks in advance.

AGW · February 2, 2021, 11:27pm

I have just started getting an error which is stopping the add-on - I don’t suppose anyone can interpret it?

(node:7) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'port' of undefined
    at setDefaults (/snapshot/app/dist/config.js:18:96)
    at Object.loadConfig (/snapshot/app/dist/config.js:65:16)
    at /snapshot/app/dist/index.js:18:29
    at Generator.next (<anonymous>)
    at /snapshot/app/dist/index.js:8:71
    at new Promise (<anonymous>)
    at /snapshot/app/dist/index.js:4:12
    at /snapshot/app/dist/index.js:17:8
    at Object.<anonymous> (/snapshot/app/dist/index.js:57:4)
    at Module._compile (pkg/prelude/bootstrap.js:1320:22)
(node:7) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:7) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

dchesterton · February 2, 2021, 11:45pm

That error is around the part of the code which sets default config values if not provided. I think you may have a problem with your config, could you post your full config on here?

AGW · February 2, 2021, 11:56pm

Ah, that is interesting. My config is blank - I’ve added it back and saved it but it disappears!

AGW · February 2, 2021, 11:57pm

I should add that I am running the 2021.2 beta. I’ll see if it lets me revert.

AGW · February 3, 2021, 12:14am

I have reverted to 2021.1.5 although I can’t see how to revert the supervisor.

I have set the add on not to start at boot or restart on a crash then restarted HA.

With texecom2mqtt stopped I add my config and press save. Then I change tab to the log and straight back to the config tab (I.e. I don’t start the add on) and my config is blank again.

Might this be a problem with HA proper rather than texecom2mqtt?

dchesterton · February 3, 2021, 12:33am

Very odd. Yeah it sounds like it is a problem with Home Assistant itself.

devotee101 · February 3, 2021, 8:21am

I think I’ve found the reason for the “expected length issues”. I’ve observed the same thing on texecom-connect and filed an issue with a fix in a PR.

I suspect the same thing is happening here, i.e. the socket doesn’t return the expected amount data so just needs a retry to get the remaining chunks. Is there any chance you could verify this theory @dchesterton? Happy to test any fixes that might come out of this.

AGW · February 3, 2021, 8:59am

Ah, there is another characteristic which may muddy the water - there is a dropdown on the config tab of all addons which allows one to select Edit in UI or Edit in YAML.

For all of my addons except texecom2mqtt it says Edit in UI, for texecom2mqtt it says Edit in YAML but is greyed out.

Does this suggest that there may be a setting which controls which option is presented to the user? Something thinks that a UI should be used (other than the YAML editor) for setting the texecom2mqtt config.

2021.2 proper is due today - that might fix it or at least cause more savvy users of the add-on than I to experience the problem!

Kind thoughts,

Andrew

dchesterton · February 4, 2021, 12:02pm

Thanks Ant, I’m currently without my main machine but I’ll look into it as soon as I can. Has your fix for texecom-connect worked as expected?

devotee101 · February 4, 2021, 12:20pm

Yes, it’s been running for just over 24 hours now with no issues.

MarkR · February 4, 2021, 1:22pm

I just want to say, amazing job thanks. This is working as I always wanted an alarm with HA to do so. I have just fitted a texecom 32w panel, with smartcom and comip. Comip is now dedicated to this and smartcom for wintex/phone alerts.

Again, thank you!

AGW · February 4, 2021, 5:02pm

The issue with editing of config has been resolved by the latest supervisor release - but I now have the same error message in the log as before.

I have done a fresh install of the add-on, edited the config, saved it and rebooted then started the add-on.

(node:7) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'port' of undefined
    at setDefaults (/snapshot/app/dist/config.js:18:96)
    at Object.loadConfig (/snapshot/app/dist/config.js:65:16)
    at /snapshot/app/dist/index.js:18:29
    at Generator.next (<anonymous>)
    at /snapshot/app/dist/index.js:8:71
    at new Promise (<anonymous>)
    at /snapshot/app/dist/index.js:4:12
    at /snapshot/app/dist/index.js:17:8
    at Object.<anonymous> (/snapshot/app/dist/index.js:57:4)
    at Module._compile (pkg/prelude/bootstrap.js:1320:22)
(node:7) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:7) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Kind thoughts,

Andrew