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.
Very nice. That represents a level of skill I can only aspire to!
In the end I managed to find a single component that did the level conversion and 12V conversion on a single board
I don’t think that that does level conversion, only runs from 12V. Fortunately, the ESP8266 is actually quite forgiving as far as tolerating 5V levels goes, so you should be ok!
I believe it does do level conversation based on para 6 .
6. Built-in 5V to 3.3V TTL level converter to prevent high-pressure Arduino TTL level of the WiFi module damage.
Also, it’s intended to be used with an Arduino which I believe is 5V?
For the benefit of others who want to do something similar I’ve written up my investigation: Connecting Texecom Premier Using Esp8266 | The Scrapheap Architect
I see that they claim that, but I don’t see any circuitry actually DOING that level conversion. Looking at the traces on the board going from the headers to the module in the middle, there are no signs of any level conversion components.
Anyway, it’s a moot point, the module itself should be ok with it, so they can claim it if they want to!
1 Like
Sorry to bump and old thread, but what’s the latest theory on best way to interface with Texecom in 2024? I have a Pi zero 2w (running ser2net) and a level converter but super overkill for what I need. I only really want to enable Creston protocol from wintex so I can view my sensors in apple HomeKit so I can automate arming as I leave etc. Whilst the pi does this (and works well) the updates heat generated im looking for a better offering. Any tips?