@levickij does all of the communication to node-red go through the com-ip, and the connect is used for the Texecom app & Wintex? (I’m trying to work out if I can do this without having to fit an additional com-ip)
Yes, that is correct, Node-RED has a dedicated interface through the com-ip, texecom connect and wintex use the Connect interface.
Thanks, I currently just have a connect. I could probably use the com-ip interface of the connect in place of the dedicated com-ip, but I would lose the ability to use Wintex / Connect at all.
Need to make sure I know how to change the com port settings from the keypad before I disable my ability to do so with Wintex!
This is my BETA Texecom Alarm set up. I use the digital outputs through an opto transistor (because panel output is 12v) D1 Mini (3.3v) and Mqtt. I power the d1 mini from the panel Aux 12v via a small adjustable buck power supply. I also set and un-set via MQTT - D1 Mini - Opto- into a zone input (set as key switch in wintex), to set and un-set the alarm.
I control my hue lights so they all come on and flash when the alarm is activated, and because i use the telecom smoke detectors, when the fire alarm is activated all my lights turn on. I also use the pir detectors (wintex zone mimic digital output setting) to auto turn on my low level lights at night when presence is detected in my hall way.
Seems to work really well, i am not sure how secure the setting and un-setting of the alarm is though, i might set it up through the home assistant alarm integration, so a code is needed. Do you think this is necessary ?
I’ve released a Docker image which fully supports Texecom and MQTT including remote arming/part arming/disarming: https://hub.docker.com/r/dchesterton/texecom2mqtt. It has Home Assistant auto-discovery built-in too.
Texecom won’t allow me to publish the source code unfortunately as I’ve signed the NDA but I hope it’s useful to someone.
2 Likes
That’s great news!
I’ve been waiting for a proper alarm, with option to manage it locally.
Is it going to work in hass.io too?
Going to get a SmartCom installed (currently using a serial cable) and give this a whirl. Many thanks.
I don’t yet have a network interface for my alarm, but have just picked up a second hand com-wifi until cheap, so hopefully I will be able to try it out with this.
Looking at your example configuration file, would I be right in thinking that I can define the zones, for instance I have a door sensor and HA will be able to see the state of this zone as a binary_sensor so I can trigger automations etc from the door opening without having to install any additional sensors on the door?
Hi Ben, that’s correct, yes. If you enable Home Assistant discovery the app should automatically create the zones you have in your alarm panel in Home Assistant.
All installed now and working well as binary sensors.
Many thanks
I’m looking to monitor my Premier 832 using HA. I don’t have an Elite panel, unfortunately.
My idea is to use an ESP32, connected to both COM1 and COM2. One COM port will be configured to use the Simple protocol, and the other will be configured as a ComGSM.
The intention is to have the panel push notifications to the ESP via the ComGSM port, as if it were talking to an ARC, but also have the ESP able to interrogate the panel for things like zone names, statuses, logs, etc using the Simple Protocol, as well as being able to monitor messages on the keypad, and arm or disarm the panel.
The ESP32 will connect to an MQTT server to share its status with other systems.
In addition, the ESP32 will listen on port 10001 for any incoming connections. If a connection is made, the ESP32 will cleanly disconnect from the panel, before shuttling bytes between the TCP socket and the serial port, supporting external systems such as Wintex or the various mobile applications. When this happens, posting an offline message via MQTT would probably be a good idea.
So, I do have some source code that should make implementing the Simple protocol easier, basically the racarter micasaverde plugin, as well as https://github.com/Samyoue/TexecomVeraPlugin, and of course, I can always reverse engineer the Wintex app as it queries all of the panel properties.
I’m not sure that the MicasaVerde and Vera plugins are sufficiently comprehensive for my purposes, and would ideally prefer to avoid having to completely reverse engineer the WinTex application/communication if possible!
Since the Simple protocol documentation is no longer available from Texecom, I’d appreciate anybody reaching out to me with a copy. 
Ok, so I made some progress with this, which I thought folks might be interested in.
Firstly, the hardware is very simple: an ESP32 module, and a TXB0104 level converter. I wired the level converter up to both ESP32-UART1 and ESP32-UART2, so that I could expose both COM ports on the 832 panel. I used the default pins for UART2, and chose GPIO26/27 for UART1, since the ESP32 can remap its pins fairly arbitrarily.
I also wired up a GPIO to the TXB0104’s enable pin so that I can disable/enable the level converter if desired. This seems not to be a good idea, because the RX pins on the ESP32’s UART then float, and cause garbled input. It might be a good idea to add a weak pulldown on the RX pins …
From a software perspective, I chose ESPHome, with a simple custom component to do the mapping from a TCP port to the UART. I found this (https://gist.github.com/oxan/4a1a36e12ebed13d31d7ed136b104959) which was almost perfect, then added a couple of mods to allow specifying the port in the constructor, so that I can run two separate stream server instances at once. I also added some debug code, so that the characters read/written to the UART’s are reported in ESPHome’s logs, which are subsequently available via USB on UART0, or over the network using esphome logs, as well as via MQTT (I’m working on a utility to process these messages to assist in reverse engineering the Wintex command stream).
Here is the ESPHome yaml I created:
esphome:
name: alarm
platform: ESP32
board: esp32dev
platformio_options:
upload_speed: 460800
includes:
- stream_server.h
- stream_server.cpp
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
captive_portal:
# Enable logging
logger:
# baud_rate: 0
# Enable Home Assistant API
api:
mqtt:
broker: home.dawes.za.net
discovery: false
log_topic: alarm/logs
ota:
time:
- platform: homeassistant
id: homeassistant_time
text_sensor:
- platform: version
name: Alarm ESPHome Version
- platform: wifi_info
ip_address:
name: Alarm IP
ssid:
name: Alarm SSID
bssid:
name: Alarm BSSID
sensor:
- platform: uptime
name: Alarm uptime
- platform: wifi_signal
name: Alarm WiFi Signal
update_interval: 60s
switch:
- platform: restart
name: Alarm Restart
- platform: gpio
id: level_converter
inverted: false
name: Enable Alarm UARTs
pin: 13
uart:
# - id: uart0
# tx_pin: GPIO1
# rx_pin: GPIO3
# baud_rate: 115200
# data_bits: 8
# parity: none
# stop_bits: 1
- id: uart1
tx_pin: GPIO26
rx_pin: GPIO27
baud_rate: 9600
data_bits: 8
parity: none
stop_bits: 1
- id: uart2
tx_pin: GPIO17
rx_pin: GPIO16
baud_rate: 19200
data_bits: 8
parity: none
stop_bits: 2
custom_component:
- lambda: |-
auto stream_server1 = new StreamServerComponent(id(uart1),10000);
return {stream_server1};
- lambda: |-
auto stream_server2 = new StreamServerComponent(id(uart2),10001);
return {stream_server2};
The panel itself is configured to have a USB-COM on both ports.
At this stage, I can connect Wintex to either TCP 10001 or 10000, and use all of the usual Wintex functionality.
My plan going forward is to write a PC-based program that receives the logs via MQTT, applies known decoding rules to the commands sent and responses received, and displays them for human consumption and further decoding. Ideally, duplicate messages will be reduced to a counter, to reduce the amount of processing/thought required!
Once sufficient understanding of the Wintex protocol has been achieved, the plan is then to migrate that understading into a second ESPHome custom component that will expose intelligent API calls to HA or other MQTT subscribers.
1 Like
Well done on the ESPHome UART - TCP bridge, this sounds a useful trick for many sorts of integration.
It looks like you made some more progress on deciphering the WinTex protocol? Great stuff.
In case it’s helpful or you’ve not seen it, there’s a python implementation of the “Texecom Connect” protocol here too:
I believe you could point that script (TEXHOST TEXPORT) at your ESP stream server and see what it does; you may need to reconfigure the relevant COM port to “SmartCom” (Texecom Connect) protocol, but the Elite panels have a degree of auto-detect between the various texecom proprietary protocols (AIUI) so it may just work.
This is the problem that I am trying to address with the Wintex protocol analysis - I have a non-Elite panel that does not support all these more recent protocols. Connect, Crestron, etc are all out of the window for me.
A small amount of progress, enough to use the zone sensors as presence sensors or door sensors, etc in HA. It would definitely be good to include support for bypassing zones, arming and disarming the alarm, and reporting when the alarm activates (and possibly reporting the LCD messages, perhaps?), but that will require further protocol analysis.
At this point, I am thinking that a derivative of GitHub - shuckc/pialarm: Interface with (and impersonate) Texecom Alarm panels over UDL protocol in python is probably the best approach to doing this. Emulate a specific panel (i.e. return the appropriate identification string on connection), then use Wintex to upload a basic configuration to the panel. Make changes in Wintex, then look at the modified memory areas to figure out what each conceptual change in Wintex translates to in the saved memory on the panel. Step through the monitoring pages to identify the memory areas responsible for each page, then (using an updated pialarm implementation) tweak bits in those memory areas to see how Wintex reports the changes.
1 Like
@RoganDawes Is there any chance you could show a wiring diagram. I’m happy with the software but the electronics are pushing my boundaries. In particular I believe the level shifter needs a HV input, but I can’t find 5v anywhere on the alarm. At the moment I’m running a raspberry pi w zero which seems you be tolerant of the 5v input but trying to move to esp8266 using rsp-link which is blowing my mind in terms of price and startup times.
Hi @adventuretwist. My ESP32 is powered from the 12V supply from the panel, through a switching supply bringing the voltage down to 5V, and then the built-in linear voltage regulator on the ESP32 board doing the final step down to 3.3V. That gives me a 5V supply for the high side of the level shifter, and a 3.3V supply from the ESP32 board for the low side.
Which panel are you using? I have actually made a fair bit of progress with my Premier 832 in recent weeks, and now have all the zones and partitions functional, including setting the alarms in Away or Stay modes (one minor detail to verify, I think I may be confusing two settings).
The main thing is that I have reliable two-stage commands working without crashing the ESP32, so adding all the rest of the settings is just a matter of time, rather than solving C++ headaches! 
Thanks. I have a Premier Elite 48. I’m currently just using the ESP for ‘ser2net’ type functionality and relying on the texecom2mqtt bridge which seems to work fine. All in I have some nice integration between HA, my Ring devices and my Texecom (physical) alarm. The electronics in the box are still untidy and I’m keen to tidy that up so it’s not all wires and dangling USB cables, but my soldering isn’t very good. I’ve got a couple of these on order which I think support 5v on UART, so I only need to handle the 12V → 5V conversion for power. Really appreciate the reply.
Yes, those modules should be ok, I think. Only downside is that you would need one for each serial port (if you wanted to allow concurrent access), since the esp8266 only has a single usable serial port.
My esp32-based build uses a scrap of veroboard to mount a common esp32 dev board, a txb0104 level converter and the 12V-5V switching supply. And then I have a short length of Ethernet cable going to the two serial ports on the panel.
Nice idea on the ethernet cable! Your set-up sounds great, but I think I’d have components and cables dropping out everywhere so I’ll keep it simple and move the complexity to software where I know how to handle it.
Yes, sad about only one serial port. I’ve seen some code (e.g GitHub - plieningerweb/esp8266-software-uart: Software UART / Software Serial / SoftUart for ESP8266 to connect more than one UART) that suggests I can bit-bang it, so might see if I can merge that into esp-link or similar.
Not complicated at all, it ends up looking something like this:
Note that this is a controller for my gate, not for my alarm panel, and is missing the level converter (and includes some optoisolators you wouldn’t need). But the idea is similar. The little green board at the top is the 12V-5V switch mode converter, the ESP32 has its own LDO. The signals are routed on the Veroboard, and then jumped across the parallel traces using jumper wires. I only soldered pins for the connections that I actually needed, so I could run signals right under the ESP32 where I needed to.
Nice and neat.