Texecom2mqtt: Texecom alarm panel and MQTT integration with HA support

Third party integrations
255

I have this issue as well after an upgrade to Supervisor 2021.02.5 this morning. Core is as 2021.2.1.

I also have the below showing in my Supervisor log.

21-02-08 12:14:24 INFO (SyncWorker_1) [supervisor.docker.interface] Cleaning addon_c15a2434_texecom2mqtt application
21-02-08 12:14:25 INFO (SyncWorker_1) [supervisor.docker.addon] Starting Docker add-on dchesterton/texecom2mqtt with version None
21-02-08 12:14:55 WARNING (MainThread) [supervisor.misc.tasks] Watchdog found a problem with c15a2434_texecom2mqtt!
21-02-08 12:14:55 WARNING (MainThread) [supervisor.addons.options] Unknown options texecom
21-02-08 12:14:55 WARNING (MainThread) [supervisor.addons.options] Unknown options mqtt
21-02-08 12:14:55 WARNING (MainThread) [supervisor.addons.options] Unknown options homeassistant
21-02-08 12:14:55 WARNING (MainThread) [supervisor.addons.options] Unknown options log
1 Like
256

I’ve raised an issue here - https://github.com/dchesterton/texecom2mqtt-hassio/issues/10

1 Like
257

After much delay I bit the bullet, updated firmware on my 48W-Live, installed Smartcom on Com1/2 and ComIP on Com3 and had a go at getting this addon running.

Got it logged on and it’s pulling sensors through so happy days so far, eek! I’m disproportionally excited about this.

2 Likes
258

It was all working perfectly but I failed to read the latest posts - Updated supervisor this afternoon and now have the same issue as above, all sensors stuck in last known state from 6+ hours ago.

Aside from this issue, super happy with the add-on :slight_smile:

1 Like
259

Yup - same boat. Seemed to die for me after disabling the alarm this morning, don’t believe there were any updates overnight although I do have the add-on to autoupdate but not HA/supervisor, so of course I went to update docker-ce, supervisor etc and ended up worse :slight_smile:

If it I understand correctly, the current work around is to deploy the addon into a non-HA docker environment?

260

I rolled back to 2021.02.4, didn’t seem to resolve the ‘Cannot read property ‘port’ of undefined’ for me.

Then I tried to uninstall this addon and reinstall, but it wouldn’t let me because it was in an ‘unhealthy’ state.

261

I think you need to go back to 2021.02.2.

262

I find a server (not just HA) reboot normally solves this. This is one reason I want to move to Debian, to get onto a more supported platform. Whenever they update Supervisor it goes unhealthy.

263

Is there a way of preventing supervisor updates from happening?

It is quite galling that a mandatory update breaks the system…

264

Yeah, it did - but then it seems/seemed to autoupdate the supervisor anyway :slight_smile:

Has been on my list to rebuild onto Debian as well.

265

Posts from last year on this forum, seem to be dirty - I think I’d rather just wait, rather than making things potentially worse :slight_smile:

266

I’m seeing the same problem as @AGW and @MarkB1. issue started earlier today - thought updating to core 2021.2.2 might help but it didn’t.
glad I’m not the only one.

Is this a supervisor update issue?

(node:6) 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 ()
at /snapshot/app/dist/index.js:8:71
at new Promise ()
at /snapshot/app/dist/index.js:4:12
at /snapshot/app/dist/index.js:17:8
at Object. (/snapshot/app/dist/index.js:57:4)
at Module._compile (pkg/prelude/bootstrap.js:1320:22)
(node:6) 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 Command-line API | Node.js v21.6.2 Documentation). (rejection id: 1)
(node:6) [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.

267

It is very much a supervisor issue - they appear to have, without warning, changed something about the way add-ons are expected/allowed to operate.

The most recent supervisor now shows this on the config page:

This add-on does not expose configuration for you to mess with… :wave:

It feels as if the powers that be at HA Towers may be behaving in a somewhat cavalier fashion.

268

Hi folks,

I am starting to work on a reverse engineered implementation of the Wintex protocol, based on a decompiled Android RKP app, as well as analysis of the protocol used by the Wintex app itself. I’m referring to a “Wintex” protocol because the Android RKP app uses Globals.UseWintexProtocol, even though I have not actually seen other references online to such a beast, only Simple and Crestron, et al.

So far I have implemented the following functions using the Wintex protocol:

  • login
  • heartbeat
  • getPanel - matches the version string to return a Java enum that contains the relevant properties of the connected panel, number of zones, partitions, users, etc.
  • getPersistentMemory(addr, length)
  • getTransientMemory(addr, length)
  • getLCDText - uses getTransientMemory
  • getZoneText - uses getPersistentMemory
  • hangup

The ultimate intention is to implement the entire protocol inside of ESPHome on an ESP32, as described in this post: Texecom Alarm panel. A TCP port will be exposed to support Wintex and phone apps using one COM port, and the other COM port will be used by ESPHome to provide zone sensor updates, alarm status, etc using the HA API and/or MQTT.

While I understand that Texecom has asked you (@dchesterton) not to provide source due to the protocol NDAs you have signed, would it be possible to share a stripped down framework of the app that includes no actual protocol implementation at all? i.e. just stub/mock functions? That would save an enormous amount of duplicated effort on my part, and would accelerate support for plain old Premier (non-Elite) panels.

I’m not sure whether you have received any documentation for the Wintex protocol, but if not, perhaps replacing the current simple/crestron protocol implementation with a Wintex implementation would allow you to bypass the NDA’s and move development out into the open?

2 Likes
269

I’ve released an update to fix the add-on issue.

Unfortunately due to a breaking change in Home Assistant it will require you to update your config file (even those not using the add-on). However, I’ve taken the opportunity to simplify the config massively which should fix a lot of the pain points with the application.

I’ve also put in quite a bit of code to validate the config so you should get a nice warning/error telling you what’s wrong and how to fix it if your config is not quite right.

The full format is on the Docker page: https://hub.docker.com/r/dchesterton/texecom2mqtt but essentially where you had something like this before:

log: 0
texecom:
  ...
mqtt:
  ...

homeassistant:
  discovery: true
  prefix: "home-assistant"
  areas:
    house:
      name: "House Alarm"
      mapping:
        full_arm: armed_away
        part_arm_1: armed_night
        part_arm_2: armed_home
      options:
        code_arm_required: true
        code_disarm_required: true
        code: 123456
  zones:
    front_door:
      device_class: "motion"
      name: "Living Room Motion Sensor"

It will now be:

log: debug
texecom:
  ...
mqtt:
  ...

homeassistant:
  discovery: true
  prefix: "home-assistant"

zones:
- id: front_door
  name: "Front Room Motion Sensor"
  device_class: "motion"

areas:
- id: house
  full_arm: armed_away
  part_arm_1: armed_night
  part_arm_2: armed_home
  code_arm_required: true
  code_disarm_required: true
  code: 123456

Additionally, I’ve fixed the versioning issue on the add-on store so you should now see an Update button in Supervisor to easily update to the latest version.

Please let me know if the fix works for you. Sorry for the delay getting it sorted and also for having to change your config but it should improve the project going forward :+1:

Edit: You may have to reload your repositories for the new version (1.0.14) to show. Go to ‘Supervisor’ -> ‘Add-on Store’, click the icon in the top right and click Reload.

1 Like
270

Hi Rogan, really nice work on the reverse engineering! I’d be keen to poke around the code when you get a chance to publish it :slight_smile:

Switching protocol is not something I’m going to do. I appreciate it’s frustrating that I can’t publish the source code but I’m using the Connect protocol (it’s different to the simple/crestron protocols) which is the modern API that Texecom want applications to use where possible and it’s also well documented and works well. I’m happy to help in any way I can to support your work with non-Elite panels though.

It’d be quite difficult to extract out the non-NDA bits from the NDA bits in the code :confused: and if I’m honest, I’m really pushed for time at the moment too. Can you sign the NDA? I’ve shared access to the repo to others who have signed it and I’d be happy to do the same with you.

271

Hi @dchesterton. Thanks, I’ll be sure to share it once I have cleaned it up a bit, and got something more functional.

I understand completely that you don’t wish to change protocol - the Wintex protocol is rather obscure, and mixes internal implementation details with exposed external API. Among other things, a lot of the protocol seems to depend on knowing specific memory regions to query, and then how to parse the resulting output as bitfields, etc. Nonetheless, it does provide the ability to interface with older panels which do not support the Connect protocol at all.

Would you perhaps consider providing it as an alternate backend, alonside the Connect protocol, to enable support for those panels in texecom2mqtt? I honestly don’t care if my reverse engineering gets incorporated elsewhere, and would be happy to provide it in a format that makes it easy for you to use. e.g. a protocol-specific implementation of a general interface.

I haven’t done any node development, but syntactically it seems easy enough.

As far as signing the NDA, it’s not something I am keen to do. I don’t particularly want to have to ask permission from anyone to share my code. And it exposes me to legal action if I share something that I believe is not covered, but someone else does. So, no.

272

@MouseZA @Alpha01-OS @MortenVinding I also have a non-Elite panel (Premier 832, in my case), and have started work on reverse-engineering/reimplementing the Wintex protocol (as used by Wintex itself) to allow monitoring/control of older panels too.

It may even be possible to implement a Connect<->Wintex shim that would allow older Premier panels to appear as a Connect-capable panel! My Panel->network interface is homebrew, based on an ESP32 connected to both COM1 and COM2 on my 832, with both ports configured as USB-COM in the panel itself. Based on a quick look at the functions specified in the Connect protocol, it should be fairly straightforward to accept Connect-protocol function calls, and translate them to Wintex protocol to the panel. It could potentially even be done in the ESP32!

273

Thank you Daniel, that update has got me back up and running! All my sensors worked straight away (as before) without any manual tweaking of settings in the config.

On this update it cleared the config back to defaults, required in this case as it needed rejigging but would make me wary of future updates. Is there a way of adding a warning to back up config first?

274

Sorry about that, I can promise that there won’t be any big changes to the config going forward. As I was forced to make a change I wanted to make a bigger change now so there’s a good foundation going forward.

1 Like