How to: integrate OH with a Texecom alarm system

Hi James,

I think this is covered by “contains”, if you look at my rule:

	val itemName = gAllecontacten.allMembers.filter[sw|sw.name.contains(in_UDPmsg.substring(1, 5))].head

So when you rule is triggered, you should have a
if contains “A00” do ABC
if contains “E00” do XYZ

Kind regards,
Dries

1 Like

Thanks, I’ll give it go!

Hi Dries

Thanks for all your work on this. I started to follow through your instructions and I would like to know if I guess correctly about the MAP files. I am using the new OH 2.4

I created 3:

tex_alarmstatus.map shows the four status for the alarm (0= disarmed 1=armed …etc)
tex_alarmusers.map 1=Dave, 2=[Another name]
tex_contacts.map I don’t know what to write here! Do I write the zone in a “friendly” name

Becasue I have no MAP files I get a lot of [WARN] in the logs. For example:

Failed transforming the state ‘NULL’ on item ‘Tex_Alarm_ArmDisarmUser’ with pattern ‘MAP(tex_alarmusers.map):%s’: Couldn’t transform value because transformation service of type ‘MAP’ is not available.

Many thanks for your help.

Dave

Hi Dave,

Sorry for the late reply. Here are my .map files:

tex_alarmstatus.map:

0=disarmed
1=armed
2=alarm being enabled
3=alarm triggered
4=failure alarming
-=Unknown
=Onbekend
NULL=Onbekend

tex_alarmusers.map

1=User1
2=User2
255=Quick Arm
0=Unknown
-=Unknown
=Unknown
NULL=Unknown

tex_contacts.map

-=Unknown
0=Closed
1=Open
2=Sabotage
=Unknown
NULL=Unknown

Let me know if that helps (or doesn’t)

Good luck!

Hi Dries

Thanks for your great Texecom integration, i’m almost there :slight_smile:

My system is with English text, and therefore I need to modify your rules a bit - Can you explain me how to debug and get the correct text in the rules?

Best Nanna

Hi

You might be able to leverage the technique that Rick kindly explains here :-

As further expanded here, when trying to extract fields from line feed delimited string from the APCaccess UPS command.

Hi Nanna,
The short answer is: check your “events.log”. You will be able to see which values are coming trough, allowing you to adapt the rules.

Additionally, there is quite some information on this forum regarding the analyzing/debugging business rules. One topic to get started (there are many more): Logging | openHAB

Good luck!

Hi Dries

Thanks for your reply, I will try to set the TCP/UDP binding in debug level and see if I can get som usefull log Entries :slight_smile:

Best Nanna

I got it working :slight_smile:

I missed to define the Tex_Get_LSTATUS Item.

Is there a way to Arm/Disarm the AIA system from your Integration?

I found your post [BasicUI - keypad], all I was looking for :slight_smile:
Best Nanna

I have a Texecom alarm panel with the Texecom SmartCom and I wanted to use that to integrate it into my openhab. I asked Texecom tech support for the documentation and they replied that they no longer offer this information to individuals/DIY installers. You now need to be a professional installer/integration company to get that. They also included a request form where you have to enter your company details, business plan for the integration, …

This sucks.

I’ve just installed an Elite 24 and SmartCom and one of the key reasons for selecting a TexeCom panel was their reported good support to DIYer installers. So yes, this sucks. Having said that, their customer support has so far been very good.

I was thinking it would be good if the panels could send/receive MQTT messages. Seems a more modern way to communicate than either a hardware interface to the Outputs - and there are only 8 of those as standard - or the Com serial protocols.

No doubt TexeCom want a slice of the Home Automation market but I suspect they are too small to dominate and be standard setters, so much better for them to offer an open interface to other HA systems.

PS this is a very useful post even if I will/hope to use the SmartCom

I’ve been looking at the Texecom installer forum and apparently the SmartCom does already speak MQTT… apparently if you use Wintex to connect to the panel via the SmartCom option it all goes through their MQTT broker. It’s just that you can’t use that option since they aren’t willing to release the documentation unless you are a “professional”.

But it’s not all bad… I did manage to get my hands on the old docs mentioned at the top of this topic - so crestron and simple protocols. You can easily establish a TCP connection to the SmartCom and talk to the panel. I managed to get the zone information and keypad display. I am just having some issues deciphering the panel status and arming (I don’t know if it’s possible to part arm the system - except through keypad emulation).

I was thinking of putting this all together into a binding, but I need to do some learning about OH development first… so I need some time to do that.

3 Likes

Hi Dries

I parked this project for a while because I’ve been busy with real work, but I’m pleased to say I’ve got it working (I use the Moxa nPort) to the point that I can control the lights with the Texecom sensors in the room. Not progressed to further testing but will update in due course.

I had made a copy/paste error in the initial config of the UDP receive item. Found the problem after 4 hours of looking! :slight_smile:

Thanks for all your work on this.

Cheers
Dave

Hi @Nanna_Agesen,

Did you use ComIP or the Moxa nPort approach?

Cheers

Gary

Hi @garymq

For integration to Openhab, I use the Moxa approach, but the alarm is still connected to the cloud with ComIP.

Best Nanna

@Dries - Thanks for the great tutorial. I’ve nearly got it working, but feel like I’m failing at the last hurdle.

I’m getting zone and arm/disarm status updates from my Texecom Premier 48, but not getting any response to either the ASTATUS or LSTATUS requests.

If I log into the Moxa nPort (I’m using a DE-311) console, I can see a character count against the Tx line.

I’ve tried to set things up as closely as possible to your great tutorial (DE-311 settings aren’t exactly the same), but somethings going wrong along the way. Any tips really appreciated.

Thanks

Julian

As a follow-on to my post above, I took at look at the UDP packets through Wireshark. All appears to be OK from the Openhab/server side of things, so I think the issue lies either with config of the Nport or Texecom board.

Hi Julian,

Happy to help.

What I don’t really understand from your message is that you are getting arm/disarm status updates, but you are not getting any updates from the ASTATUS message. But a.f.a.i.k, you only get arm/disarm updates after you are sending the ASTATUS message.

Assuming you are not getting arm/disarm status updates:
Have you tried using Wireshark to send the ASTATUS (or LSTATUS) to the Moxa? Are you getting a response then?

Make sure the Moxa accepts these messages (see “Accessible IP Settings”)

Dries,

Thanks for helping. I get arm/disarm messages - when I arm/disarm the system through transmission of an A0xxx or D0xxx message. I just don’t get any response to the ASTATUS or LSTATUS send commands, which makes me wonder whether they’re getting through

Incidently, I’ve just finished moving Openhab from my Win10 PC (where I was just dipping my toes in) to an Odroid C2 (dedicated to the task). The zone messages etc. are still getting through, but I can’t see anything registered on Wireshark now! Really strange…

The Moxa is an old model - only has a text interface - and doesn’t appear to have any setting along the lines of “Accessible IP settings”.

One basic question - I’ve currently got the ports for incoming/outgoing set to different values (Moxa sends to Openhab server @ 9999, and listens on 9998) Is this OK?

Thanks

Julian