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.
Thanks for your great Texecom integration, i’m almost there
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
MDAR
(Stuart Hanlon, UK importer of Velbus hardware)
17
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
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, …
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.
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!
@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.
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.
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”)
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?