Integrating Texecom Premier Alarm Panels via ESPHome using Wintex protocol

RoganDawes · January 4, 2024, 10:09pm

Meh, thought it would be simple, but trying the rebase with those changes ends up with garbage in the various entity names. Guess I’m going to have to dig a bit more!

You could try just checking out my wintex_v2 branch as is, and building using the version of esphome that that branch is derived from, but you’ll be on a pretty old version of ESPHome.

timbo-82 · January 5, 2024, 9:02pm

Ahh no, thanks for taking a look though. I will give your branch a spin and see how goes this weekend!

Thanks again for taking a look!

RoganDawes · January 6, 2024, 4:41am

My current theory is that since the code is presuming that the incoming string constants are in flash, it is creating a StringRef (std::string compatible) that simply points to the address of the char *, and assumes that it will never go away or be used for anything else. My code is creating the .c_str() on the stack, and therefore the char * does go away, and gets replaced with binary garbage.

Couple of possibilities to solve this:

rewrite everything so that the strings are created in python, written out in one piece in main.cpp. This is more like ESPHome’s preference for not magically creating entities that are not explicitly called out in the yaml. I didn’t want to do this, because it ends up being an enormous amount of configuration, as well as setters and getters to support each field. 32 zones * 8+ binary sensors and a switch per zone, 2 or 4 partitions with 32 binary sensors per partition, etc. That said, it would then allow the rest of the ESPHome ecosystem to be applied, such as binary sensor filters, etc, for a flapping PIR or some such. (Personally, that probably needs to be fixed by replacing the PIR rather than papering over it externally, since the panel can’t benefit from ESPHome filters!)
Allocate the string on the heap using new so it doesn’t go away. Might have to make them static otherwise they might get garbage collected anyway. But that won’t work unless I allocate an array indexed by zone number, since I end up calling the same function for multiple zones.

timbo-82 · January 11, 2024, 5:09pm

yeah i can understand the hesitation for option 1 it can get out of control quickly. option 2 could work, and seems simpler but im no expert.

I might be blind, but i dont seem to see a wintex_v2 branch on the repo. i can try the main branch and see if i can find out how to load an old version of esphome.

EDIT: ok im really feeling stupid right now, how can i tell what version of ESPHome this was initially compiled on #facepalm

RoganDawes · January 12, 2024, 4:40am

is probably going to be the correct approach, and implement the alarm_control_panel: interface at the same time. Will take a bit of time to get to it, though.

Here is the tree: GitHub - RoganDawes/esphome at wintex_v2

git clone --branch wintex_v2 https://github.com/RoganDawes/esphome wintex_v2
cd wintex_v2
python3 -m venv dev
. ./dev/bin/activate
script/setup

Now you should be able to change to the directory where your alarm.yaml config is and run it (esphome run alarm.yaml). When you are done messing around with this specific version of esphome for the alarm, run deactivate to exit the virtual environment (venv).

timbo-82 · January 12, 2024, 5:50am

thanks,

I will try this out. appreciate it.

zerkos · July 30, 2024, 8:18am

Hi Rogan

I decided to write to you after a detail reading of all your precious posts here and other forums

I have a Texecom Premier 816 Plus version 3.6 with only ONE COM PORT, and I am trying to intergrade it to HA.

I have already managed to program my ESP32 with your code, connecting a logic lever converter for the communication and with the Oxan’s stream server I managed to talk with the official Wintex program and with the panel wireless, so far so good.

The problem I am facing is when I am trying to connect to my Texecom panel via ESPHome using your Wintex protocol I have some sort of communication but the alarm panel returns Authentication failed.(I attached the image below). Can you explain to me what is the meaning of all these digits and how can I decode them, I only understand the line the esp32 sends with the UDL password 38:38:38:38.

I feel that I am too close to implement your gorgeous project. What I am missing?

Thanks in Advance.

Kosmas

RoganDawes · July 30, 2024, 12:03pm

Hi Zerkos,

The easiest way to figure out what the problem is is likely to be to dump the Wintex traffic generated by the official program. When using oxan’s Stream Server, make sure that the uart debugging is enabled, then use the official program to authenticate to the panel. Then disconnect again. Checking the uart debug logs should show you the Wintex sequences sent and received. Then compare those to what my ESPHome program does.

It’s reasonably likely that there is a confusion in PIN encoding. IIRC (it’s been a while!) I send 1 2 3 4 as 01 02 03 04, or possibly the ASCII codes of 31 32 33 34. Maybe your panel is expecting it to be the other way?

zerkos · July 31, 2024, 7:03am

Thanks Rogan for the reply,
How can i send the 8888 udl code as 08 08 08 08 as you did?

RoganDawes · July 31, 2024, 12:12pm

That code is here:

github.com

RoganDawes/esphome/blob/a67d718998ca4005eb6c23b23527cf886cf84001/esphome/components/wintex/wintex.h#L312


      
          class Wintex : public Component, public uart::UARTDevice {
            friend class WintexButton;
            friend class WintexPartition;
            friend class WintexZone;
          
           public:
            float get_setup_priority() const override { return setup_priority::DATA; }
            void setup() override;
            void loop() override;
            void dump_config() override;
            void set_udl(std::string udl) {
              this->login_ = AsyncWintexCommand(WintexCommandType::SESSION, std::vector<uint8_t>{udl.begin(), udl.end()},
                                                [this](WintexResponse response) { return this->handle_login_(response); });
            }
            void register_zone(WintexZone *zone);
            void register_partition(WintexPartition *partition);
            WintexVoltageSensor *system_voltage, *battery_voltage;
          
           protected:
            void queue_command_(AsyncWintexCommand command);
            void register_sensor(WintexSensorBase *sensor);

But as far as I can see, that will only let you send 38 38 38 38, because it converts the ASCII characters “8 8 8 8”, rather than taking the offset from zero. Maybe you can subtract 0x30 from each character in the string before creating the login command? Not 100% sure on the best way to approach that, tbh.

zerkos · August 3, 2024, 1:45pm

Thanks Rogan.

I’ll check it out.
I am preparing for vacations now.
I’ll keep in touch.

zerkos · August 7, 2024, 8:27am

Sorry Rogan but i dont know how to do that. i have zero skills in programming.

RoganDawes · August 7, 2024, 11:05am

It actually looks like you can escape non-printable characters in a double quoted string in yaml, so something like:

wintex:
  udl: "\x08\x08\x08\x08"

might do the trick?

zerkos · August 7, 2024, 2:19pm

Rogan that was very clever of you.
No Authentication Failed any more.

I will check the rest and will keep you informed.

THANK YOU …

RoganDawes · August 7, 2024, 2:47pm

Hah! I’m glad that worked!

The remaining hurdles you may encounter revolve around possible variations in memory locations for the status of alarm zones. If it does not work out of the box with the 832’s addresses, you will need to use the Texecom Wintex program to do some live monitoring of the alarm panel via the stream_server: while recording the output. That will reveal the addresses, and an update can be made accordingly.